/[dtapublic]/sf_code/esrgweba/htdocs/authindiv/dtashley/bad_management/index.html
ViewVC logotype

Contents of /sf_code/esrgweba/htdocs/authindiv/dtashley/bad_management/index.html

Parent Directory Parent Directory | Revision Log Revision Log


Revision 23 - (show annotations) (download) (as text)
Sat Oct 8 06:11:57 2016 UTC (7 years, 5 months ago) by dashley
File MIME type: text/html
File size: 11924 byte(s)
Initial commit.
1 <html>
2
3 <head>
4 <meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
5 <meta name="GENERATOR" content="Microsoft FrontPage 4.0">
6 <meta name="ProgId" content="FrontPage.Editor.Document">
7 <title>Dave's Observations And Thoughts About Bad Management In Embedded
8 Software Development</title>
9 <base target="main">
10 <bgsound src="../../../gensounds/austin_powers/beat_drevil.wav" loop="0">
11 </head>
12
13 <body background="../../../bkgnds/bk10.gif">
14
15 <p align="center"><b><font size="5">Dave's Observations And Thoughts About Bad
16 Management In Embedded Software Development</font></b></p>
17 <hr>
18 <p><b><u>Bookmarks</u></b></p>
19
20 <ul>
21 <li><a href="#intro" target="_self">Introduction</a></li>
22 <li><a href="#what_achieve" target="_self">What Is One Trying To Achieve In A Software
23 Development?</a></li>
24 <li><a href="#perfdil_immat_man" target="_self">Performance Dilution By Technically Immature
25 Management</a></li>
26 <li><a href="#coevolution" target="_self">Co-Evolution</a></li>
27 <li><a href="#light_bulb_analogy" target="_self">The Light Bulb Analogy</a></li>
28 <li><a href="#emotional_manipulation" target="_self">Emotional Manipulation Of Employees</a></li>
29 <li><a href="#recognize_but_resist" target="_self">Recognizing Problems But Resisting
30 Solutions</a></li>
31 </ul>
32 <hr>
33 <p><b><u><a name="intro"></a>Introduction</u></b></p>
34
35 <p>I (Dave Ashley) have become really cautious about which recruiters I deal
36 with, which employment interviews I consent to, and which job offers I accept.&nbsp;
37 Understandably, my caution comes from experience.</p>
38
39 <p>Generally speaking, the management in the auto industry involved with the
40 development of small embedded systems is the <i>worst</i>
41 management I've seen anywhere.&nbsp; The general components of the poor
42 management performance and low-quality work environments are discussed at some length in
43 the following sections.</p>
44
45 <p>Some might claim I have a <i>bad attitude</i>.&nbsp; Nothing could be further
46 from the truth.&nbsp; In most cases the key issue is an elusive quality that
47 I'll call <i>technical maturity</i>.&nbsp; Some people (specifically, the bad
48 supervisors and managers I've had the dishonor of working with) go their entire careers and never grasp
49 the essential nature of the technical and management problems they confront on a
50 daily basis.&nbsp; That <i>failure to technically mature</i> does not make these
51 individuals <i>morally</i> defective--it just makes them <i> technically</i>
52 defective.&nbsp; My desire to distance myself from such individuals doesn't come
53 from anti-social tendencies; but rather from the self-preservation
54 instinct.</p>
55
56 <p>I'm very much reminded of a quote from one of the Superman movies where Lex
57 Luthor (Gene Hackman) <font size="6">(</font><img border="0" src="lex_luthor.jpg" align="absmiddle" hspace="5" vspace="5" width="53" height="73"><font size="6">)</font>
58 delivers a line something like, &quot;<i>Otis, why is it that some people can
59 read the list of ingredients on a chewing gum wrapper and unlock the secrets of
60 the universe while others can read `War and Peace' and come away thinking it is
61 a simple adventure novel?</i>&quot;.&nbsp; How true, Lex, how true!&nbsp; Some
62 people don't get it and won't <i> ever</i> get it.</p>
63
64 <p>Much of the remainder of this page is devoted to observations about
65 management that has failed to technically mature.</p>
66
67 <hr>
68 <p><b><u><a name="what_achieve"></a>What Is One Trying To Achieve In Software
69 Development?</u></b></p>
70 <p>Before slamming bad management for failing to <i>get it</i>, one should state
71 what it is that needs to be gotten.&nbsp; What is one trying to achieve in
72 software development?</p>
73
74 <p>On the administrative side, the bare minimum that one is trying to achieve is
75 <i><b>administrative neatness</b></i>.&nbsp; In modern software development, neatness
76 is <i>not</i> neatly-labeled file folders and <i>Microsoft Word</i>®
77 documents with attractive cover pages and attractive headers and
78 footers.&nbsp; <i>Neatness</i> is a <b> comprehensive information management plan</b>
79 that:</p>
80
81 <ul>
82 <li><b>Minimizes reliance on paper.</b>&nbsp; Treeware <i>is</i> necessary
83 sometimes.&nbsp; Personally, I've found that when I'm reviewing something
84 complex I <i>must</i> have it on paper.&nbsp; However, web-based databases
85 and paperless technologies are now the norm.</li>
86 <li><b>Addresses the needs and usage scenarios of everyone who participates in
87 the software development.</b>&nbsp; Everyone who participates in software
88 development or testing needs electronic resources to store their work
89 products.</li>
90 <li><b>Minimizes redundancy of information.</b>&nbsp; Although it is
91 impossible to eliminate information redundancy entirely, one must make a
92 best attempt.&nbsp; The <i>first</i> level of attempt is to have a <i>policy</i>
93 for where all product development information is stored: this prevents
94 unnecessary redundancy because all employees know where each type of
95 information should be stored.&nbsp; The <i>second</i> level of attempt is to
96 complement any policy weaknesses with tools that maintain information
97 consistency automatically.&nbsp; Unfortunately, most software development
98 organizations do not even make it to the first level of attempt.</li>
99 </ul>
100
101 <p>On the human resources side, the bare minimum one is trying to achieve
102 is to <i><b>create the most rewarding experience for the top 10% of technical
103 contributors</b></i>.&nbsp; Not all engineers or employees contribute
104 equally.&nbsp; The 10% of engineers/employees that contribute the most
105 technically to product development tend to have unstable personalities (these
106 are the people you want to keep away from customers, for example).&nbsp; These
107 individuals tend to strive for technical excellence, and don't tolerate
108 environments that dilute their productivity.&nbsp; So, it makes sense for an
109 employer to try to create an environment free of performance obstacles so as to
110 be able to retain these individuals.</p>
111 <p>I'm not claiming that an employer needs to <i>identify</i> the top 10% of
112 technical contributors in order to be effective at retaining these
113 people.&nbsp;&nbsp;All that is necessary is to create an environment where those
114 who wish to perform can do so.</p>
115 <p>It may be difficult to for the reader to envision a scenario that creates a
116 low-quality experience for a solid technical contributor.&nbsp; A concrete
117 example is that &quot;coding standards&quot; example, which I present next in
118 the section <a href="#perfdil_immat_man" target="_self">Performance Dilution By Technically
119 Immature Management</a>.</p>
120 <hr>
121 <p><b><u><a name="perfdil_immat_man"></a>Performance Dilution By Technically
122 Immature Management</u></b></p>
123 <p>One phenomenon that drives away gifted engineers is <i>performance dilution
124 by technically immature management</i>.&nbsp; The nature of the phenomenon is
125 that management often doesn't understand the work or the nature of the work well
126 enough to make sound decisions; and some of the decisions (or failures to make
127 decisions) invariably lower the quality of life for engineers.&nbsp; The most
128 gifted engineers tend to have the strongest desire to contribute to the
129 company's productivity, and so these decisions tend to frustrate the most gifted
130 engineers into leaving the company.&nbsp; The net effect is to place an upper
131 limit on the caliber of employees the company can retain.</p>
132 <p>The phenomenon of differentially frustrating employees is also mentioned by
133 Colin Powell in his awesome presentation, <i>A Leadership Primer</i> (available <a href="powellonleadership.zip">here</a>
134 as a .ZIP'd PowerPoint presentation).&nbsp; The bottom line is that the most
135 productive employees are most sensitive to obstacles to their
136 productivity.&nbsp; The graphic below is from Powell's presentation.</p>
137 <p align="center"><img border="0" src="powell_01.gif" width="720" height="540"></p>
138 <p>One example from my own career is the issue of <i>coding standards</i>.&nbsp;
139 At one point in my career with a large company, I was given responsibility for
140 products that were politely called <i>legacy products</i>.&nbsp; <i>Legacy
141 products</i> was a euphemism for products that had been poorly-designed and
142 modified too many times.</p>
143 <p>Each file that I opened in these legacy products contained inconsistent
144 indentation and a mixture of space and tab characters (something that is
145 prohibited by most coding standards).&nbsp; Because 'C' functions in embedded
146 work can be quite lengthy, the net result is that I had to&nbsp;replace all tabs
147 with spaces and then manually indent about 10,000 lines of code.&nbsp; It was an
148 unpleasant experience.</p>
149 <p>During the experience, I discussed with my boss the need for coding standards
150 that prohibit tab characters in source files.&nbsp; He was unenthusiastic about
151 coding standards in general, and nothing ever got done.&nbsp; The net result was
152 sure to be that more source files with inconsistent indentation were coming my
153 way.</p>
154 <p>The general trend with bad management is:</p>
155 <ul>
156 <li>Engineers will suggest process, technical, or administrative improvements
157 to management.&nbsp; (Often, these suggestions come directly from situations
158 in the work place that are lowering the quality of life for engineers.)</li>
159 <li>The management will not be technically mature enough to understand the
160 merit of the suggestions and/or will be insensitive to the way in which the
161 current situation lowers the quality of work life for engineers.</li>
162 <li>The suggestions will not be implemented at all, or in a best case some of
163 the suggestions will be implemented (but always the suggestions--usually the
164 least strategically important ones--that are consistent with the technical
165 maturity of the management).</li>
166 <li>The most gifted engineers (who are usually more sensitive to the
167 frustration) leave the company.</li>
168 </ul>
169
170 <hr>
171 <p><b><u><a name="coevolution"></a>Co-Evolution</u></b></p>
172 <p>One question I often ask myself is &quot;<i>How did things get so bad in
173 small embedded work?</i>&quot;.</p>
174 <p>I'm convinced that the answer lies in evolution and co-evolution.&nbsp; From
175 time to time, one may watch a nature special where in some dark cave with a
176 closed ecosystem, a species of blind fish has evolved.&nbsp; Blind fish can
177 exist in such an environment because they do not need to see.</p>
178 <p>Similarly, I'm convinced that the poor management skills abundant in small
179 embedded work come from the environment.&nbsp; Every project is small enough
180 that one can just keep throwing people at it and somehow the work will get done,
181 even without a design.&nbsp; Skill <i>is not</i> necessary.&nbsp; A large pool
182 of young energetic engineers who are easily deceived and manipulated <i>is</i>
183 necessary.</p>
184 <p>In projects of higher complexity, the same approach would fail miserably.</p>
185 <p><b>Q:</b>&nbsp; Why are the supervisors and managers of small embedded
186 software products so bad?</p>
187 <p><b>A:</b>&nbsp; Because they <i>can</i> be (the complexity of the product
188 allows it).&nbsp;</p>
189 <hr>
190 <p><b><u><a name="light_bulb_analogy"></a>The Light Bulb Analogy</u></b></p>
191 <p>&nbsp;</p>
192 <p>&nbsp;</p>
193 <hr>
194 <p><b><u><a name="emotional_manipulation"></a>Emotional Manipulation Of
195 Employees</u></b></p>
196 <p>&nbsp;</p>
197 <hr>
198 <p><b><u><a name="recognize_but_resist"></a>Recognizing Problems But Resisting
199 Solutions</u></b></p>
200 <p>&nbsp;</p>
201
202 <hr>
203 <p align="center" style="margin-top: -2; margin-bottom: -1"><font size="1">Sound
204 credit:&nbsp; The <i>Austin Powers</i> series of films starring Mike Meyers.<br>
205 This
206 web page is maintained by <a href="mailto:dtashley@users.sourceforge.net">David
207 T. Ashley</a>.<br>$Header: /cvsroot/esrg/sfesrg/esrgweba/htdocs/authindiv/dtashley/bad_management/index.html,v 1.7 2003/05/10 00:28:43 dtashley Exp $</font></p>
208 <hr noshade size="5">
209
210 </body>
211
212 </html>

dashley@gmail.com
ViewVC Help
Powered by ViewVC 1.1.25