Rules for engineering

Dan Maslowski is a philosopher among the the Sun bloggers. The following piece is an example. You may visit his blog to find more: http://blogs.sun.com/danmas


I read with interest the article by our legal type doing the legal thing on legal leadership. (NB: Anyone besides me notice that there is a picture of him but no name... Whom is him?) The article resonated with me and helps me provide a structure for some of the basic tenants of leadership I follow as it relates to engineering management. So, here is a crack at some of the rules I live by. I will post more as time goes on:
Engineers should attend all key business and staff meetings.

Engineers are important players in key decisions because we understand the technology of “how” things work. The business team should decide why and what we do, but engineering has a significant understanding of the technology that can be useful in solving the business problems.

While attending these meetings, it is important to understand that influencing people and decisions is an important part of the job. Attacking or vilifying (technical arrogance anyone?) is bound to be counter-productive and lead to not only distractions but dissatisfaction and a subsequent waning of the influence that engineer might have had.

Eliminate the “No” word from your vocabulary.

Business teams make decisions and seek advice and input from engineering. It is really easy to explain why an idea is stupid. In fact, I can pay someone $5 an hour to tell me how bad an idea is. The point is that it is easy to shoot things down. It is much harder to figure out how to make things work, solve problems creatively and come up with a scenario that works both technically and for the business.

Additionally, it is important to quantify the decision criteria. Instead of saying “No, doing foo is a stupid idea”, engineers could say “At this time I don't know how to do foo” or “Doing foo will cost you n number of months of engineering time and n number of $. Balance that against existing tasks and tell me what you would like to do.” In this manner we accomplish our role (advise on what to do and how to do it) but still leave the decision maker the ability to make the decisions that count. This street credibility is invaluable. Helping our teams to make the correct decisions should be based on facts and influence, not technical nay saying.

Engineers should be business people. Hone your business ability.

The longer I am in engineering, the more convinced I am that doing is much simpler (for me) than figuring out what to do. I can build a computer (program, chip, application, utility etc.). The really hard thing (OK slightly tongue in cheek, engineering is hard too), at least for me, is figuring out what to build, when to build it and how to sell it. I am not detracting from the rare and beautiful talent associated with building and creating. These are great things and are the foundations of our success as an engineering centric company (and customer centric). Knowing that we need to build low cost, low power servers to take back market share in servers is genius however. (Did you hear we are number 3 again? Sorry Dell...)

Engineers must take every chance to be customer centric and customer focused. Jerry Vogel at AMD talks about customer centric engineering. I had the benefit of hearing Jerry speak when I attended the Experienced Managers Academy (essentially the “I wanna be a director” school for AMD leadership) and it was a profound experience. Jerry intuitively understands that success is defined by our partners and our partnerships with our customers. Business with our customers is and should be a personal thing. It is pretty clear to me that the AMD-Sun partnership is, well, a partnership.

Many of our (engineering's) customers are the marketing and sales teams. The entire value chain consists of building the right thing at the right time and sales/marketing will tell us this if we listen.

Finally, we are in business. Failing to understand key business statistics and metrics (ROI, WACC, ERP, TCO etc) prevents us from understanding how to influence either these statistics or the people that make decisions based on these statistics.

Return phone calls and email promptly.

Recall that one of the key roles for an engineer is to influence decision making. The frustration associated with not being able to reach an engineer or being able to solicit advice is extreme. It results in splits between team members and fracturing of relationships. Build and maintain those relationships such that when it really counts, the relationship and the problem solving and influencing skills are intact and ready for use.

Learn about business problems and proposed solutions early.

Some of my greatest success stories involve solving a problem with already crafted solutions before lots of money and effort were spent trying to spin up a new program. Since we are, in a sense, the technical historians of our business, we have a wealth of tested and produced solutions at our finger tips. If we are intimately involved in our business, we can put that history to use and use it to influence key decision makers.

Simplicity is beautiful.

A simple solution is far more elegant than a complex solution. I “made my bones” in writing software that tried to espouse the following guidelines:

The user should never need to ask the question “What do I do now?” The design should preclude the user from needing to reference a manual or look at something else to move forward. This is very hard to do and requires great sophistication.


Things should just work. No configuration, no hoops to jump through, no magic rocks to grok or arcane rituals to perform. Plug it in, turn it on and go. Anything else is a failure of the “what do I do now” rule. If you need to know the secret knock in order to proceed the design is flawed.

Write your code such that a new graduate can work in the code base without undue effort or initiation. There are no style points for complex code, terse commentary or mind bending and intricate interactions. Simple, discrete and straight forward code is beautiful. It reduces the total cost of ownership, eases maintenance and reduces sustaining costs. Most importantly it guarantees that I can bend my talents to solving new and interesting problems, not maintaining an obscure and difficult code base.