As a systems engineer,  your job is to explain a novel idea to other systems engineers,  developers, testers,  and possibly external customers.  The information to share with the different information customers may vary but they all require explaining the same design.  An idea is a strange thing,  it may germinate differently in different minds depending on level of knowledge,  preconceptions, similar experiences,  or the general disposition of the person on the day.  Thus,  the idea must be developed and exposed using the maximum level of clarity.  The best way to achieve this is to explain the same concept thoroughly and from different angles:

A) Introduce the topic.  Start by describing the design at a high level. Stress any high level concepts such as applicability, benefits, prerequisites, general workings of design, and affected functions. Next, provide an architecture diagram showing the various functions in the system and identifying the affected functionality. Where applicable, show the control and data flows within your diagrams.

B) Provide a detailed description of the design. Divide the idea or design into atomic topics, order the topics to ensure a good flow for the presentation of the ideas, and then tackle the sub-topics one by one. For each sub-topic: 

B1) Describe the issue in detail. For every functional box describe the inputs, outputs, and operations. For every  algorithm provide a step by step description. For every message, describe field descriptions and actions at source and destination related to the packets and fields.

B2) Add pictures. Humans are visual beings. Beside the aforementioned architecture diagram, add figures to explain the detailed workings of your design. The diagrams may zoom in on parts of the architecture diagram to show a finer level of detail of the interactions between the various functions.  Try to have at least one picture per slide if presenting, and an introductory section with good illustrations per main chapter if writing a design description document.

B3) Include flow charts for algorithms. A flow chart accompanies the step by step description of each algorithm.

B4) Add use cases. Use cases describe the various ways a product will be used.  It is true that, by this point, the functionality has been described textually and in pictures. However,  use cases will dig into specific examples of how the product will work.  Start with the main use cases,  and then cover all corner cases.

B5) Add call flows. Call flows describe the exchange of messages between different functions within a product, or between different nodes of a system.  Frequently,  a use case can be fully described by a call flow.

Review your document repeatedly to ensure a good flow.

Finally, clean up the document of any typos or mismatched styles and fonts. You don’t want cosmetics to distract from your message.

Configurability is one of the most crucial, and one of the most frequently mishandled, features of a product.

A good configuration enables crucial calibration and evolution of a product to meet evolving external conditions.

Systems engineers must provide a list of configurable variables with explanation of usage,  impact to product, range of settable values, default value, and within the range of settable values, the list of values to test. The test list has a multiplive effect on unit testing,  and potentially on system test.  The rookie systems engineer may define too many configuration variables, and large ranges of values to test,  only to find out later, that only the default values have been tested for many of the configuration variables due to time constraints. The experienced systems engineer will define the minimum set of configuration variables, and restrict as much as possible the testable range space. The engineer may highlight hard coded variables that may be candidates for future change so that the plumbing is created to enable adding configurability to these variables, if desired, in future product updates.

In my rookie days, I worked helter skelter with a bunch of good willed engineers. I tried my best but hated criticism. I would work alone, preparing my design, consult a few times with my direct lead, then run a concept review followed by the actual design review. Once the design was reviewed by systems, the design was reviewed by the software and test teams. The software and test teams used to be so much behind that they did not see the design until 3 months after it was done by systems. At that point, I was reluctant to make changes. In any case, I received comments as criticism to my work and sought to avoid them.

With more experience, I have tried to involve as many co-workers as possible in my design work. Feedback is a way of canvassing the knowledge in the team to improve the design. At the end of the day, the software team knows what is the simplest implementation, and the test team knows the pain points encountered in previous testing. Obtaining this knowledge and being flexible in modifying the design to incorporate the comments leads to the best design possible. This will also lead to improved thinking and clarity on the part of the designer and will lead to more efficient designs in the future.

I have experienced negative feedback on my approach but only by occasional contributors. These occasional comentors may believe that they are correcting a flawed design while what they are really doing is being a part of the design team on a quest for the best feasible design. People who work with me love this approach as they feel a sense of ownership of the design.

Finally, I would like to comment that this should never be design by consensus. The designer should still spend a lot of time coming up with original approaches and vetting his or her ideas with colleagues until convinced on the best approach. The designer should have the strength of their conviction when discussing the design and push it through if negative feedback is unconvincing. The goal is to always push the envelope within the limits of the solution space.

At one point or another, you will find that a team is struggling to deliver. The most frequent signs of trouble in my experience are:

1. A rejection of every proposal as too complicated. The struggling team will reject every proposed enhancement or change as too complicated. Every small change will be associated with a disproportionate man month estimate. In general, one must trust the estimates returned by the team specialized in each layer and task. However, estimates that don’t make sense are an indication that the corresponding team have lost the handle on their product.
2. A reluctance to provide time estimates. Time estimates are always given with a grain of salt. Every engineer worth his salt will provide one. It may be optimistic, pessimistic or on the money but a confident engineer will give an estimate. A struggling team may refuse to give an estimate even if it is understood that the estimate is a loose one.
3. An overly protective lead. Bad habits, like good ones, require gentle handling to blossom. An overly protective lead may overly protect his team in bad times leading to a loss in accountability and openness.
4. A defensive attitude. An us against them mentality and a refusal to accept just criticism are hallmarks of struggling teams that are in denial. Defensiveness of this kind goes against the healthy ethos of information sharing and open discussion. It may be needed when interacting with other companies (although, even there, a more balanced approach works better), but it is poison to improvement when applied in-house.
5. Turnovers. When a team is struggling, the good and nimble players will scramble away first. Some good stubborn apples may remain but the core strength of the team will be weakened.
6. Finger pointing. This is the ugliest red flag. I recall working on a project where the team could not deliver a firmware update and constantly had bugs in their system. The team finally identified one of the junior engineers and blamed him for checking in code without properly notifying the team members. The guy may have done a mistake but he was most likely trying to compensate for the chronic failures around him. Ten years later, the scapegoat is leading a firmware team and his prior bosses have been laid off or have left the company.

Previous to my current job, I used to work with a competitor, let’s call it company E. I had started to help the standards team at E, contributing ideas to our standards proposals. The standards groups, at the time, were in the midst of defining a new radio access technology. We proposed what we thought was a good design. Lo and behold, the company I work for now, let’s call it Q, had contributed a standards design as well. Their design was inferior to ours and had obvious flaws. We were relieved. However, in the next couple of cycles of standards meeting, Q brought up updates to their proposal where they closed all the loopholes. Their design formed the bulk of the new standard.

The morale is that good companies present a moving, ever improving, target. Weak ones will give it their best shot but then stagnate.

The same applies to groups within a company. A strong group will successfully fix the flaws in its product. A weak group will be overwhelmed by the size of the fixes and will stagnate and fail.

At a micro level, the same can be said of individuals 🙂