The Prepared's podcast + A history of The Public Radio

Some updates!

So, I've been working on some stuff. 

First: Thanks to The Prepared's *awesome* donors, I've redesigned and relaunched theprepared.org. Awesome!

Second: In the spirit of expanding The Prepared's purview (which is why I'm taking donations in the first place), we now have a podcast! The goal of it, as with this newsletter, is to help people prepare for good work - and to share the results of the big things they've worked on. To kick things off, we've got two episodes: One with Zach on the history and future of Centerline Labs, the company we cofounded to create The Public Radio, and one with Zach and Gabe about some of the things we're thinking about on the eve of...

Third: The Public Radio's launch on Kickstarter! I'm very excited about this, and it deserves a bit of explanation:

The Public Radio started in 2013 as a longshot side project - "a product idea for a single-band FM radio," as I described it four years ago. Going back through my blog while filtering for the "publicradio" tag shows a funny story. Early on, I posted a lot of "this was my workday" posts. Then there was more topical content - my struggles finding the right potentiometer; little thoughts on how to take crowdfunding offline. In early 2014 Adafruit posted something short about us, and shortly after we soft launched. 

All of that was under looks-like prototypes; it wasn't until mid 2014 that we had a works-like, which we assembled (without SMT stencils! we were so naive) by hand. At this point the design iterations were more substantial, but it wasn't until late that year - after our first Kickstarter campaign - that things really became serious.

At this point we started getting some real attention, and a bit of backlash as well. It's worth mentioning that at the time, my days were spent consulting for Bank of America and GE on management & marketing strategy; The Public Radio was a weird thing to match that with. But it was getting *fun* - real engineering problems, real supply chain problems; real business problems; real press coverage; my first injection molded part. I was interviewed by New Hampshire Public Radio and by Matthew Lesko, the guy who wears the question mark suit on old '80s infomercials. 

And then, all of the sudden, we (with the oh-so-gracious help of friends/family/indentured servants) shipped 2500 radios to people all over the world. We missed our Kickstarter shipping goals by about a week; pretty good.

Almost immediately afterwards, we went to China to plan for v2.0. We visited our speaker supplier in Dongguan and roamed the Shenzhen electronics markets, and did all of the other things you'd expect. But as we were heading back to the US, my day job was in the process of vaporizing, and for the ensuing two years The Public Radio has largely been relegated to the odd warranty email.

So, this relaunch. The thing is, The Public Radio is a good product, and we want to find a way for it to live on. This is harder than it sounds. No matter how much the traditional supply chains are being (*cough*) disrupted, it's still really hard to run a hardware business in your spare time. The Public Radio is an incredibly simple device - intentionally so - and yet it's real work to get it made.

But we're trying anyway. We've got a pretty nice plan here - one that keeps TPR lean on capital requirements, keeps our supply chain short, and (most importantly) makes for a really nice customer experience. There's a lot to unpack here, and you can bet that I'll be sharing more here in the next few months :)

Anyway, that's that. Please, check out The Public Radio on Kickstarter and share it!!!! They look great, work great, and make for *excellent* gifts. And as we build out our manufacturing process, you'll be right there learning about it with us!

Good at it

This week I experienced a few moments - fleeting, but palpable - of being good at it. 

It was a nice feeling: A combination of knowledge, experience, and at least a bit of maturity. It was the feeling of having all of your tools laid out in just the right place. The feeling of finding a rhythm. The feeling of knowing exactly how much energy you've got, and pacing your sprint so that you *just* exhaust all of it.

Of course, I continue to make mistakes. Things rarely move as quickly as I hope, and rarely am I satisfied with the results. But when I look back, I can see my own work working - and I'm pretty sure it's not accidental.

I know the feeling isn't permanent; even writing this now, it seems a far way off. But I've been building for a while now, and even a fleeting reprieve is pretty great :)

Responsibility

From  a very thorough retrospective of Boston's Big Dig project:

But the Big Dig's biggest pitfall was that Massachusetts never understood a basic fact: that it couldn't pay someone else to assume its own responsibility for an immensely complex, risky project.

I'm continually surprised that people don't know know and internalize this.

Notes on Arcam and SLM

Yesterday, GE announced that they had put in bids to acquire both Arcam and SLM for a combined total of $1.4B. This move poses some interesting questions about the next few years in industrial AM, and will no doubt have a big impact on both the companies involved and their customers and competitors. I don't have any privileged insight into any of these companies' decision making process, but I have a longstanding interest in the industry and what they're working on. Here are a few observations & questions that occurred to me about the deals and their impact.

Background

In 2012, GE Aviation made three large acquisitions in industrial AM. The first was the combined purchase of Morris Technologies and Rapid Quality Manufacturing, two sister companies based in Cincinnati who had already been a big supplier to GE Aviation (terms of the deal were not disclosed). Later that year, they bought Avio Aero, and Italian parts supplier, for $4.3B. These two purchases showed an interesting balance in technologies. While Morris and Avio had very similar business models (both were job shops that produced parts for GE Aviation and other business units; Avio also produces parts by traditional manufacturing methods), they focused on different additive technologies: Morris on laser, and Avio on EBM.

I've written about the difference between laser and EBM in the past, but a few points here:

• The fuel nozzle that GE is so famous for printing is made by laser in Auburn, Alabama on EOS machines. I believe that their (lesser known) T25 temperature sensor is made on the same machines.
• The laser (Note: I'm using "laser" here to refer to processes that are variously called DMLM, SLM, DMLS, lasercusing, and the generic "laser metal powder bed fusion." Note also that SLM can be used to refer both to the printing process AND to the machine manufacturer that GE just acquired.) machine market has a number of providers: Aside from EOS and SLM (the two machine manufacturers that GE is most known for using) there's Renishaw, Concept Laser, Additive Industries, 3D Systems, and a variety of Chinese entrants.
• While GE Aviation has tended towards EOS machines (see the video above), GE Power & Water uses machines made by SLM in their Greenville, SC plant (Note: Here I'm drawing from an AMUG 2015 and other industry sources; sorry for the lack of a hyperlink reference).
• Arcam sits apart from these: it's currently the only company making machines for EBM (electron beam melting, or "electron beam metal powder bed fusion" if you're picky).
• Avio Aero has done some really interesting things with EBM since the GE acquisition. Perhaps most notably, last year they printed low pressure turbine blades out of titanium aluminide, an intermetallic alloy. TiAl has excellent mechanical properties at high temperatures (an important feature of any part that's in the hot stage of a jet engine), and is traditionally cast by companies like Precision Castparts Corp (PCC). Printing in TiAl brings advantages but is extremely difficult due to the material's tendency to fracture. Printing TiAl could be a big deal as GE ramps up production of TiAl blades for the GEnx engine, and it was very interesting to note that after the successful prints, Avio bought an additional ten Arcam systems - the largest purchase that Arcam had ever accepted.

So: GE already had a strong portfolio in additive. What are the implications of the Arcam and SLM acquisitions, and how will this impact the industry?

A full stack, in-house

The most interesting part of the acquisition to me is the fact that GE will now be able to in-house the entire industrial AM supply chain (minus software; more on that below). Previously, they were focused primarily on basic research and applications development (Morris, Avio, CATA, and the Niskayuna Global Research Center) and serial part production (Auburn, Greenville, and Avio). Now, they'll own not one but two machine manufacturers - allowing them to push upstream and make a more direct impact on the development of the additive industry.

But perhaps more importantly, GE gains both powder production (through AP&C, the Canadian powder supplier that Arcam acquired for CAD 35MM in 2014) and final parts manufacturing (through DiSanto, the medical implants manufacturer that Arcam acquired for $18.5M later the same year). When Morris was acquired, they shut down their sales organization and focused on printing parts for internal GE customers. DiSanto is a very different business, though, and I wonder whether it might make sense as part of GE's healthcare unit - with its traditional focus on medical imaging and healthcare IT.

AP&C is a bit of a different beast. They manufacture the raw materials for not only powder bed fusion but also MIM, HIP, and other powder metallurgy applications. Their website advertises commercially pure titanium and ti64, but Arcam also markets cobalt-chrome - which both the fuel nozzle and the T25 sensor housing are made of. I'll be very curious to see whether AP&C continues selling powders to the public, or if they focus on internal use.

Improving - and selling - manufacturing machines

Separate and apart from the implications to GE's internal operations, I'm particularly interested in the way that GE's involvement at these new levels of the tech stack will affect how the industry matures. Try though they may, it's difficult for a company whose bottom line depends on selling machines (as opposed to, say, selling machines AND printing parts, or selling machines AND developing manufacturing software) to truly impact the end-to-end engineering process much. And while GE has been at the forefront of additive research (and, no doubt, collaborates very closely with both their hardware and software providers), I'm hopeful that having them at the helm will push both EBM and laser powder bed fusion forward in a cohesive way. 

Some might suggest that keeping expertise in house would be the strategic choice here, but I disagree. Powder bed fusion today suffers from both a lack of talent (easiest to change by expanding the number of use cases for the process, many of which GE ultimately is not going to compete on) and a lack of process predictability and reliability. GE has more knowledge about improving AM part yield than just about anyone else in the world, but that doesn't mean that there aren't other approaches that they're not trying. Inasmuch as sharing whatever process improvements they come up with will encourage others to try their own approaches, I hope that GE does just that. And they have in the past: through their involvement with standards and industry organizations like America Makes, 3MF, and ASTM F42; through their participation in sessions at AMUG and RAPID, and through their open innovation work (some of which I worked on while at Undercurrent) with GrabCAD and NineSigma.

My hope would be that GE continues to market and improve both SLM and Arcam machines. The latter is particularly dear to me, as EBM equipment isn't currently made by anyone else (and because I've had many parts printed on Arcam machines). SLM is a bit different, as the market for laser powder bed fusion is already so rich. But by that same rationale, the potential impact that any updates to SLM's machines would have could be huge, as they would force other players to respond in kind.

Software

I take GE at their word: They want to be a contemporary engineering company, and they believe that contemporary engineering companies need formidable software capabilities. And if they're going to truly make their mark with a software solution, it would be wise to do so in a realm where they know the problems well.

Even before these acquisitions, GE knew the pain points in additive as well as anyone else. Adding a few machine manufacturers, plus a raw materials supplier and a finished parts manufacturer, will only help that along. So my question is this: Why wouldn't GE make a play in additive manufacturing software? This is, after all, the whole subtext behind the Brilliant Factories initiative: GE knows how hard it is to make things, and they can help you make them better.

As you'll know from my previous writing, I'm excited for advances in build processing (see netfabb and Magics), build simulation (see 3DSim and Pan Computing, and research by Wayne King at LLNL), and in-process monitoring & control (see Sigma Labs, plus the product spec sheets for a *lot* of the current class of laser printers). Each of these is extremely hard in itself, and recreating the entire stack would be extraordinarily complex; I don't expect any one company to solve (or even attempt) them all. But whether they build their own solutions or work with external providers to build them, GE will be a huge stakeholder in the next generation of additive manufacturing software. And if they're serious about being a formidable software company, then why wouldn't they take a shot at building it themselves?

Regardless of how these acquisitions shake out, the next year should be interesting. I'm looking forward to it :)

Being in New York

A few days ago I went to hear Ron Conway, Fred Wilson, and Michael Bloomberg speak about investing, entrepreneurship, and civic engagement. At a few moments during the event, the conversation turned to the current state of business (specifically startups) in New York City, a topic I've been thinking a lot about recently.

I feel passionately about working in New York. So much good work - across such a wide range of disciplines - has been and is being done here. And between the vast feeling of cross-pollination, and the fact that people come here specifically to do stuff of historic proportions - to make the most of their lives - is unlike anywhere else I've ever been (outside of urban China).

On a daily basis I look up and feel these pangs of energy, and wonder, and appreciation. I feel it talking to the Burmese cab driver bringing me back down North Conduit Ave from JFK. I feel it walking off the A/C train, and out through the old AT&T Long Lines headquarters, and onto Canal St and the morning in lower Manhattan. I feel it when I'm walking my dog around Bed Stuy at night and look up, through streetlights dappled by sycamores, to nod at someone smoking a joint on their stoop.

And I feel it in my work. As Bloomberg said this evening: If you want to make a business that serves the world, you need to go where the world is. And I believe that it is here more than anywhere that the many aspects of human life and work coexist best.

NYC has proven time and again that it's capable of spinning up and maturing fully fledged industries. And while many cities tend to go from one primary industry to another with little overlap, NYC somehow manages to grow and sustain many world-class operations at once. This is perhaps the most powerful part of working here: the ability to cross from industry to industry on a daily basis, and to develop long term relationships with people operating in totally different time scales.

I'm enriched by it. It's a world class place to work, and there's no better city to spend your life in.

Coherence

This photo is of a conference table in Alcoa's headquarters:

View fullsize

If it's not clear, this little inlay is made from aluminum. Which is pretty rad, considering that Alcoa is an aluminum company.

As a project manager, I'm all about choosing the right tool for the job. But I'm also all about using the tools that are available to me in the most effective ways. This table didn't need an aluminum inlay, but the aluminum inlay that Alcoa gave it worked pretty damn well.

No small slips

Also from The Mythical Man-Month:

Let us consider an example. Suppose a task is estimated at 12 man-months and assigned to three men for four months, and that there are measurable mileposts A, B, C, D, which are scheduled to fall at the end of each month. Now suppose the first milepost is not reached until two months have elapsed. What are the alternatives facing the manager?

...

3. Reschedule. I like the advice given by P. Fagg, an experienced hardware engineer, "Take no small slips." That is, allow enough time in the new schedule to ensure that the work can be carefully and thoroughly done, and that rescheduling will not have to be done again.

If you need to reschedule, take responsibility - and make sure you only need to reschedule once. 

This book is good.

Conceptual Integrity

I'm reading The Mythical Man-Month, and this section jumped out at me hard. Emphasis is mine:

Most European cathedrals show differences in plan or architectural style between parts built in different generations by different builders. The later builders were tempted to ''improve'' upon the designs of the earlier ones, to reflect both changes in fashion and differences in individual taste. So the peaceful Norman transept abuts and contradicts the soaring Gothic nave, and the result proclaims the pridefulness of the builders as much as the glory of
God.

Against these, the architectural unity of Reims stands in glorious contrast. The joy that stirs the beholder comes as much from the integrity of the design as from any particular excellences. As the guidebook tells, this integrity was achieved by the self-abnegation of eight generations of builders, each of whom sacrificed some of his ideas so that the whole might be of pure design. The result proclaims not only the glory of God, but also His power to salvage fallen men from their pride.

Even though they have not taken centuries to build, most programming systems reflect conceptual disunity far worse than that of cathedrals. Usually this arises not from a serial succession of master designers, but from the separation of design into many tasks done by many men.

I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.

It's not that I don't like Chartres; indeed, there's something incredible about projects that outlive their original intent. But when it comes to the most compelling products & systems in my life, I find conceptual integrity to be a *really* powerful force.

See also: the last section in One type of swing, etc.

Exploration and explanation

Apropos of Displaced in space or time, and just generally along the lines of what I spend a *lot* of time thinking about these days, a few thoughts on Michael Nielsen's recent post titled Toward an exploratory medium for mathematics. Note that my comments are largely placed in the field of CAD, while Nielsen is talking about math; hopefully the result isn't overly confusing.

Nielsen begins by separating out exploration from explanation:

Many experimental cognitive media are intended as explanations... By contrast, the prototype medium we'll develop is intended as part of an open-ended environment for exploration and discovery. Of course, exploration and discovery is a very different process to explanation, and so requires a different kind of medium.

I've touched on the explanatory aspects of CAD in the past (see in particular Computer aided design), but I had never really considered the dichotomy between exploration and explanation in such stark terms. This is partly a result of the fact that most CAD software has documentation built right into it. I've spent a *lot* of time using CAD tools to document parts in both 2D (multi-view PDFs) and 3D (STEP, STL, etc), and have had long conversations with engineers who swear up and down that design tools that don't make documentation easy aren't worth the time of day. 

My inclination is to think that the future will be increasingly integrated - in other words, that the divide between exploration and explanation is antiquated. But perhaps it's more useful to consider the many ways that (multifunctional CAD systems notwithstanding) these two aspects of engineering really have very little overlap. After all, my own CAD software has distinctly different interfaces for the two activities, and the way that I interact with the design interface is very different from the way my manufacturing partners will interact with my design explanations. Perhaps these activities could split even further; I see no a priori reason that this would be harmful at all.

Anyway, onward. Again, Nielsen - now talking specifically about the exploratory side of mathematics:

What we'd ideally like is a medium supporting what we will call semi-concrete reasoning. It would simultaneously provide: (1) the ability to compute concretely, to apply constraints, and to make inferences, i.e., all the benefits we expect a digital computer to apply... and (2) the benefits of paper-and-pencil, notably the flexibility to explore and make inferences about impossible worlds. As we've seen, there is tension between these two requirements. Yet is is highly desirable that both be satisfied simultaneously if we are to build a powerful exploratory medium for doing mathematics. That is true not just in the medium I have described, but in any exploratory medium.

I'll just pause here to say that this idea of "semi-concrete reasoning" is fantastic. Humans are quite capable of holding conflicting values at the same time; if computers are to be our partners in design, they'll need to do some analog of the same.

Instead of using our medium's data model to represent mathematical reality, we can instead use the medium's data model to represent the user's current state of mathematical knowledge. This makes sense, since in an exploratory medium we are not trying to describe what is true – by assumption, we don't know that, and are trying to figure it out – but rather what the user currently knows, and how to best support further inference.

Having adopted this point of view, user interface operations correspond to changes in the user's state of mathematical knowledge, and thus also make changes in the medium's model of that state. There is no problem with inconsistency, because the medium's job is only to model the user's current state of knowledge, and that state of knowledge may well be inconsistent. In a sense, we're actually asking the computer to do less, at least in some ways, by ignoring constraints. And that makes for a more powerful medium.

On this point, I agree that inconsistency itself isn't an issue at all - so long as it's made explicit to the user at all times. If a design fails to meet my needs for, say, manufacturability, then I should have some way of knowing that immediately - whether or not I choose to deal with it now or ever. Again, Nielsen:

Ideally, an exploratory medium would help the user make inferences, give the user control over how these inferences are made, and make it easy for the user to understand and track the chain of reasoning.

Yes.

Using the medium to support only a single stage of inference has several benefits. It naturally makes the chain of inference legible, since it mirrors the way we do inference with paper-and-pencil, every step made explicit, while nonetheless reducing tedious computational work, and helping the user understand what inferences are possible. It's also natural psychologically, since the user is already thinking in terms of these relationships, having defined the objects this way. Finally, and perhaps most importantly, it limits the scope of the interface design problem, since we need not design separate interfaces for the unlimited(!) number of possible inferences. Rather, for every interface operation generating a mathematical object, we need to design a corresponding interface to propagate changes. That's a challenging but finite design problem. Indeed, in the worst case, a “completely manual” interface like that presented earlier may in general be used.

With that said, one could imagine media which perform multiple stages of inference in a single step, such as our medium modifying ss in response to changes in the tangent. Designing such a medium would be much more challenging, since potentially many more relationships are involved (meaning more interfaces need to be exposed to the user), and it is also substantially harder to make the chain of reasoning legible to the user.

Even with the simplification of doing single-step inference, there are still many challenging design problems to be solved. Most obviously, we've left open the problem of designing interfaces to support these single stages of inference. In general, solving this interface design problem is an open-ended empirical and psychological question. It's an empirical question insofar as different modes of inference may be useful in different mathematical proofs. And it is a psychological question, insofar as different interfaces may be more or less natural for the user. Every kind of relationship possible in the medium will require its own interface, and thus present a new design challenge. The simplest way to meet that challenge is to use a default-to-manual-editing strategy, mirroring paper-and-pencil.

I recognize that this is a somewhat long quote, but I think it's really critical. To paraphrase: Designing a UI that allows for multidimensional problems is *hard,* and it's hard for human users to glean actionable information from multidimensional data. 

Instead, we should break UIs up into discrete steps, allowing users to visualize and understand relationships piecewise. This means more individual UI modalities need to be designed, but by defaulting to manual editing strategies - which are damn good (viz. paper and pencil) to start with - even that task becomes manageable.

There's a lot here; I recommend reading the original post in its entirety. 

Don't let anyone add any features

Just a quick note:

I can't tell you how many times over the past year I've congratulated Zach and myself, in retrospect, for pulling off The Public Radio like we did. Specifically, that we didn't listen to *anyone* who asked us for new features.

We sold an FM radio in a mason jar, and we packaged it in kraft paper and a brown Uline box. People had asked for rechargeable batteries, and solar charging, and a headphone jack, and a multi-station option, and all other manner of things. We also considered retail packaging, and replacing our potentiometer with a rotary encoder, and (if we go way back) using a custom CNCd enclosure for the radio.

I really, really, can't emphasize this enough: The fact that we ignored our own urges, and politely told everyone else that what they were asking for was "on our backlog," is the only reason that we were able to deliver The Public Radio anything close to on time. 

Delivering a product is *hard,* and you don't get any bonus points for having a CNCd enclosure. Seriously. Don't let anyone add any features.

Allen on science, engineering, and modes of information transfer

Over the past week I've been reading Thomas J. Allen's Managing the Flow of Technology, which summarizes about a decade of MIT Sloan research into how R&D organizations acquire and transmit knowledge. A number of passages have jumped out to me, and I wanted to comment on them here. Emphasis is mine throughout.

The distinction between science and engineering is key to this book. On page 3:

The scientist's principal goal is a published paper. The technologist's goal is to produce some physical change in the world. This difference in orientation, and the subsequent difference in the nature of the products of the two, has profound implications for those concerned with supplying information to either of the two activities.

And on page 5:

...whereas the provision of information in science involves the gathering, organizing, and distribution of publications, the situation in technology is very different. The technologist must obtain his information either through the very difficult task of decoding and translating physically encoded information or by relying upon direct personal contact and communication with other technologists. His reliance upon the written word will be much less than that of the scientist. 

Starting on page 39:

THE NATURE OF TECHNOLOGY
The differences between science and technology lie not only in the kinds of people who are attracted to them; they are basic to the nature of the activities themselves. Both science and technology develop in a cumulative manner, with each new advance building upon and being a product of vast quantities of work that have gone before. In science all of the work up to any point can be found permanently recorded in literature, which serves as a repository for all scientific knowledge. The cumulative nature of science can be demonstrated quite clearly (Price, 1965a, 1970) by the way in which citations among scientific journal articles cluster and form a regular pattern of development over time.

A journal system has been developed in most technologies that in many ways emulates the system originally developed by scientists; yet the literature published in the majority of these journals lack, as Price (1965a, 1970) has shown, one of the fundamental characteristics of the scientific literature: it does not cumulate or build upon itself as does the scientific literature. Citations to previous papers or patents are fewer and are most often to the author's own work. Publication occupies a position of less importance than it does in science where it serves to document the end product and establish priority. Because published information is at best secondary to the actual utilization of the technical innovation, this archival is not as essential to ensure the technologist that he is properly credited by future generations. The names of Wilbur and Orville Wright are not remembered because they published papers. As pointed out in chapter 1, the technologist's principal legacy to posterity is encoded in physical, not verbal, structure. Consequently the technologist publishes less and devotes less time to reading than do scientists.

Information is transferred in technology primarily through personal contact. Even in this, however, the technologist differs markedly from the scientist. Scientists working at the frontier of a particular specialty know each other and associate together in what Derek Price has called "invisible colleges." They keep track of one another's work through visits, seminars, and small invitational conferences, supplemented by an informal exchange of written material long before it reaches archival publication. Technologists, on the other hand, keep abreast of their field by close association with co-workers in their own organization. They are limited in forming invisible colleges by the imposition of organizational barriers.

I'll pause here to note that this bothers me somewhat. I enjoy few things more than learning from other people, especially if they inhabit different worlds than I do. Allen continues:

BUREAUCRATIC ORGANIZATION
Unlike scientists, the vast majority of technologists are employed by organization with a well-defined mission (profit, national defense, space exploration, pollution abatement, and so forth). Mission-oriented organizations necessarily demand of their technologists a degree of identification unknown in most scientific circles. This organizational identification works in two ways to exclude the technologist from informal communication channels outside his organization. First, he is inhibited by the requirements that he work only on problems that are of interest to his employer, and second, he must refrain from early disclosure of the results of his research in order to maintain his employer's advantage over competitors. Both of these constraints violate the rather strong scientific norms that underlie and form the basis of the invisible college. The first of these norms demands that science be free to choose its own problems and that the community of colleagues be the only judges of the relative importance of possible areas of investigation, and the second is that the substantive findings of research are to be fully assigned and communicated to the entire research community. The industrial organization, by preventing its employers from adhering to these two norms, impedes the formation by technologists of anything resembling an invisible college.

Incidentally, I believe that companies lose more by inhibiting cross pollination than they gain by protecting their competitive position. It would appear that Allen would agree, at least to an extent. On page 42:

The Effect of Turnover
It is this author's suspicion that much of the proprietary protectionism in industry is far overplayed. Despite all of the organizational efforts to prevent it, the state of the art in technology propagates quite rapidly. Either there are too many martinis consumed at engineering conventions or some other mechanism is at work. This other mechanism may well be the itinerant engineer, who passes through quite a number of organizations over the course of a career...

Each time that an engineer leaves an employer, voluntarily or otherwise, he carries some knowledge of the employer's operations, experience, and current technology with him. We are gradually coming to realize that human beings are the most effective carriers of information and that the best way to transfer information between organizations or social systems is to physically transfer a human carrier. Roberts' studies (Roberts and Wainer, 1967) marshal impressive evidence for the effective transfer of space technology from quasi-academic institutions to the industrial sector and eventually to commercial applications in those instances in which technologists left university laboratories to establish their own businesses. This finding is especially impressive in view of the general failure to find evidence of successful transfer of space technology by any other mechanism, despite the fact that many techniques have been tried and a substantial amount of money has been invested in promoting the transfer.

This certainly makes sense. Ideas have no real existence outside of the minds of men. Ideas can be represented in verbal or graphic form, but such representation is necessarily incomplete and cannot be easily structured to fit new situations. The human brain has a capacity for flexibly restructuring information in a manner that has never been approached by even the most sophisticated computer programs. [Just jumping in here to say bravo. -SW] For truly effective transfer of technical information, we must make use of this human ability to recode and restructure information so that it fits into new contexts and situations. Consequently, the best way to transfer technical information is to move a human carrier. The high turnover among engineers results in a heavy migration from organization to organization and is therefore a very effective mechanism for disseminating technology throughout an industry and often to other industries. Every time an engineer changes jobs he brings with him a record of his experiences on the former job and a great amount of what his former organization considers "proprietary" information. Now, of course, the information is usually quite perishable, and its value decays rapidly with time. But a continual flow of engineers among the firms of an industry ensures that no single firm is very far behind in knowledge of what its competitors are doing. So the mere existence of high turnover among R&D personnel vitiates much of the protectionism accorded proprietary information.

As for turnover itself, it is well known that most organizations attempt to minimize it. If all of the above is even partially true, a low level of turnover could be seriously damaging to the interests of the organization. Actually, however, quite the opposite is true. A certain amount of turnover may be not only desirable but absolutely essential to the survival of a technical organization, although just what the optimum turnover level is for an organization is a question that remains to be answered. It will vary from one situation to the next and is highly dependent upon the rate at which the organization's technical staff is growing. After all, it is the influx of new engineers that is most beneficial to the organization, not the exodus of old ones. When growth rate is high, turnover can be low. An organization that is not growing should welcome or encourage turnover. The Engineers' Joint Council figure of 12 percent may even be below the optimum for some organizations. Despite the costs of hiring and processing new personnel, an organization might desire an even higher level of turnover. Although it is impossible to place a price tag on the new state-of-the-art information that is brought in by new employees, it may very well more than counterbalance the costs of hiring. This would be true at least to the point where turnover becomes disruptive to the morale and functioning of the organization. 

Allen also discusses the degree two which academia influences technology development. On page 51:

Project Hindsight was the first of a series of attempts to trace technological advances back to their scientific origins. Within the twenty-year horizon of its backward search, Hindsight was able to find very little contribution from basic science (Sherwin and Isenson, 1967). In most cases, the trail ran cold before reaching any activity that could be considered basic research. In Isenson's words, "It would appear that most advances in the technological state of the art are based on no more recent advances than Ohm's Law or Maxwell's equations."

On page 52:

In yet another recent study, Langrish found little support for a strong science-technology interaction. Langrish wisely avoided the problem of differentiating science from technology. He categorized research by the type of institution in which it was conducted - industry, university, or government establishment. In tracing eighty-four award-winning innovations to their origins, he found that "the role of university as a source of ideas for [industrial] innovation is fairly small" (Langrish, 1971) and that "university science and industrial technology are two quite separate activities which occasionally come into contact with each other" (Langrish, 1969). He argued very strongly that most university basic research is totally irrelevant to societal needs and can be only partially justified for its contributions through training of students.

That's tough stuff, if you ask me. Incidentally, I've considered many times recently whether I myself would go to college if I was just graduating high school today. It would not be a straightforward choice.

Then Allen turned to the qualities of the things that engineers actually read. On page 70:

A MORE DETAILED EXAMINATION OF WRITTEN MEDIA
Looking first at the identity of the publications that were read, there are two major categories of publications that engineers use. The first of these might be called formal literature. It comprises books, professional journals, trade publications, and other media that are normally available to the public and have few, if any, restrictions on their distribution. Informal publications, on the other hand, are published by organizations usually for their own internal use; they often contain proprietary material and for that reason are given a very limited distribution. On the average, engineers divide their attention between the two media on about an equal basis, only slightly favoring the informal publications (table 4.3). Because engineering reports are usually much longer than journal articles and because books are used only very briefly for quite specific purposes, each instance of report reading takes twice as long as an instance of journal or book reading. The net result is a threefold greater expenditure of time on informal reports. We can conclude from this brief overview that the unpublished engineering report occupies a position that is at least as important as that of the book or journal in the average engineer's reading portfolio.

Here I should note that I read this through the lens of someone whose public blog is essentially an ongoing and highly detailed series of informal reports. I'm certainly no scientist, and in general my writing isn't particularly academic. I'm doing decidedly applied work, and I document it (including what most companies would call proprietary information about my products and the results of my research) for anyone to read and repurpose as they please. 

Allen continues, explaining why engineering journals aren't really used by practicing engineers. On page 73:

The publications of the professional engineering societies in all of these diverse fields are little used by their intended audience.

Why should this be so? The answer is not difficult to find. Most professional engineering journals are utterly incomprehensible to the average engineer. They often rely heavily upon mathematical presentations, which can be understood by only a limited audience. The average engineer has been away from the university for a number of years and has usually allowed his mathematical skills to degenerate. Even if he understood the mathematics at one time, it is unlikely that he can now. The articles, even in engineering society journals, are written for a very limited audience, usually those few at the very forefront of a technology. Just as in science, the goal of the author is not to communicate to the outsider but to gain for himself the recognition of his peers.

It's funny: the purpose of this blog is to communicate with outsiders AND gain the recognition of my peers. I'd like to think, in fact, that it fits the description of the ideal engineering literature that Allen puts forth on page 75:

The professional societies could publish a literature form whose technical content is high, but which is understandable by the audience to whom it is directed...The task is not an impossible one. Engineers will read journals when these journals are written in a form and style that they can comprehend. Furthermore, technological information can be provided in this form. Why then do the professional societies continue to publish material that only a small minority of their membership can use? If this information can be provided in a form that the average engineer can understand, why haven't the professional societies done so?

The obvious answer to these questions is that the societies have only recently become aware of the problem. In the past, they were almost totally ignorant of even the composition of their membership, and they still know littler of their information needs. Thus, they have never had the necessary information to formulate realistic goals or policy. Perhaps the most unfortunate circumstance that ever befell the engineering profession in the United States is that at the time when it first developed a self-awareness and began to form professional societies, it looked to the scientific societies, which had then existed for over 200 years, to determine their form and function.

Interestingly, though, I do not fit the description of the engineer that Allen gives on page 99:

THE IMPORTANCE OF COMMUNICATION WITHIN THE LABORATORY
Most engineers are employed by bureaucratic organizations. Academic scientists are not. The engineer sees the organization as controller of the only reward system of any real importance to him and patterns his behavior accordingly. While the academic scientist finds his principal reference group and feels a high proportion of his influence from outside the organization, for the engineer, the exogenous forces simply do not exist. The organization in which he is employed controls his pay, his promotions, and, to a very great extent, his prestige in the community.

To be clear, I get a ton out of working closely with people. I worked alone building bikes for a full three years, and was solo and very isolated during much of the two year construction project I completed after college; the lack of camaraderie in those situations was hard on me. I learned through that process that working with people - and having a mutual feeling of respect and enthusiasm - was incredibly important. I've gotten a ton out of all of the colleagues I've had since then - including many who I initially clashed with.

But exogenous forces in my life absolutely exist, and are important too. I benefit greatly from keeping contact with people elsewhere in my industry - and people outside of it - and I'm confident that the companies I've worked for have benefited from my network too.

My belief is that there's more room for these things to coexist than most companies realize. As evidence, I would present that when I began working on metal 3D printing, I knew nothing about it - and didn't work at a company that had any particular interest about it in the first place. I believe that it is only through my openness that I've gotten where I am today, and through that openness I've also vastly improved my access to experienced engineers across the industry. I've gotten cold emails from people working at some of the biggest and most advanced R&D organizations in the world, something I don't think would ever have happened had I not shared the way I did. And I'm confident that the my relationships with these people are mutually beneficial - both to us as people and to the companies who employ us.

I'm about a third through Managing the Flow of Technology now; I'll probably finish it in the next month. I recommend it.

Displaced in space or time

Recently a friend sent me a link to a blog post titled CAD Is a Lie: Generative Design to the Rescue. In it, Autodesk’s Jeff Kowalski touches on many of the points I made in Computer aided design, and in some cases takes a position that opposes mine. About Dreamcatcher's design process, he writes:

This is the computer becoming creative and able to generate ideas that people help to develop. Beyond creativity, the sea change is the computer’s ability to learn.

I’ve spent a lot of time over the past month thinking about these two sentences, and I still don’t know what to make of them. Allow me to work through a few thoughts.

Creativity and autonomy

As I've written here before, I'm excited for CAD software to be increasingly embedded with knowledge about how designs relate to the real world (there are some early ideas here, and here, and here, etc). But I wouldn't say that I was looking for creativity per se - and I'm skeptical that Kowalski is either.

Kowalski describes a process in which "you describe your well-stated problem, and then, using generative methods, the computer creates a large set of potential solutions." This is a fine idea in and of itself, but it doesn't have anything to do with creativity - and to confuse the two would be a fundamental mistake.

Creativity is the process of coming up with original ideas, and a huge part of creativity is the ability to recontextualize - and often times reject outright - the problem that you've been assigned. But if I were to give my computer a "well-stated problem," then it would be counterproductive to allow it to answer creatively. Creativity is in direct opposition to well-stated problems, which are meant to be solved directly - not usurped. 

In Environmental humanism through robots, Nicholas Negroponte describes these limitations - and offers a vision for what a computer-as-design-partner would need to look like:

What probably distinguishes a talented, competent designer is his ability both to provide [designs] and to provide for missing information. Any environmental design task is characterized by an astounding amount of unavailable or undeterminable information. Part of the design process is, in effect, the procurement of this information. Some is gathered by doing research in the preliminary design stages. Some is obtained through experience, overlaying and applying a seasoned wisdom. Other chunks of information are gained through prediction, induction and guesswork. Finally, some information is handled randomly, playfully, whimsically, personally.

It is reasonable to assume that the presence of machines, of automation in general, will provide for some of the omitted and difficult-to-acquire information. However, it would appear foolish to suppose that, when machines know how to design, there will be no missing information or that a single designer can give the machine all that it needs. Consequently, we need robots that can work with missing information. To do this, they must understand our metaphors, must solicit information on their own, must acquire experiences, must talk to a wide variety of people, must improve over time, and must be intelligent. They must recognize context, particularly changes in goals and changes in meaning brought about by changes in context.

Here Negroponte is saying that Artificial General Intelligence (which itself is no small feat; for an overview of AGI and what it would actually mean in practice, see this fantastic Wait But Why post) is a prerequisite for true Computer Aided Design. He's also saying that once we develop true CAD systems, we'll have to abandon the command-and-control attitude that we have towards today's robot underlings: Essentially, that we'll need to accept their refusal to solve our well-stated problems at all. 

Human machine interfaces

Kowalski also overstates our ability to define well-stated problems in the first place. As I wrote in Computer aided design, "optimization software has only just begun the task of rethinking how engineers tell their computers what kind of decisions they need them to make." As David Mindell describes in Our Robots, Ourselves, commercial aviation is much farther ahead on this point (emphasis mine):

[Heads up displays] represent a new approach to the problem: an innovation which, while certainly “high tech,” is an innovation in the humans’ role in the system. Rather than sitting back and monitoring, the pilots are actively involved. Again, sometimes more automated is actually a less sophisticated solution...as we look for solutions to automation problems that arise in aviation and other domains, we should seek innovations in how we combine people and machines, rather than simply adding additional equipment and software. Some of these innovations have been called “information automation,” which provides data in new forms to human pilots, as opposed to “control automation,” which actually flies the aircraft for them.

With the advent of automation, pilots needed new ways of communicating with their airplanes. Heads up displays, and their abstraction from "pitch and power" to "flight path and energy," provided that. If we're to move beyond the age of computer aided documentation, engineers will need new methods of communicating design intent. What will that look like? 

As Bill Mitchell (again, via David Mindell's book) said of autonomous cars, "The dashboard should be an interface to the city, not an interface to the engine.” As I wrote in Directions in automation adoption, some areas of robotics are already heading this way. BMW would never ask their Kuka robots to automatically generate optimal toolpaths; that would be unnecessarily complex to engineer, and the result would lack a critical dose of judgement and flexibility. Instead, they ask that their bots complete a straightforward task: follow a toolpath that a human operator defines manually.

In BMW's case, the human is never really "out of the loop" - something I suspect is important in human-machine collaboration. Again I'll quote Mindell's book, this time writing now about space travel:

Nearly fifty years ago, when Neil Armstrong landed the lunar module on the moon, he had both a HUD and an autoland. The HUD was an early, passive design—a series of angle markings etched into Armstrong’s window. The onboard computer read out a number on an LED-like display, and if Armstrong positioned his head correctly he could look through that angle marked on the window. Directly behind the indicated number, then, he saw the actual spot on the moon that the computer was flying him toward. 

If he didn’t like the designated area because of rocks or craters, he could give a momentary jog to the joystick in his hand and “redesignate” the landing area fore, aft, or right or left, almost like moving a cursor with a mouse to tell the computer where to land. The computer would then recalculate the trajectory it would use to guide the landing, and give him a new number for where to look. Armstrong could redesignate the landing zone as many times as he liked in a human/machine collaboration that allowed the two to converge and agree on the ideal landing zone, whence the autoland would bring the craft safely down.

But Armstrong never used the autoland. On Apollo 11, he didn’t like the spot the computer had selected for him because there was a crater, and rocks were in the way. Rather than redesignate, a few hundred feet above the moon’s surface he turned off the automated feature and landed in a less automated mode...

The space shuttle, too, had an autoland system...On every single flight, the shuttle commanders turned off the automation well before landing and hand flew the vehicle to the ground.

I asked former shuttle commanders why they didn’t use the autoland even though they had trained for it in simulators and in simulated landings in the shuttle practice aircraft. They responded that if something had gone wrong and they needed to intervene manually, it would be too difficult and disruptive to “get into the loop” so near to the landing (also, the sensitive ground equipment required to guide the autoland was not available at all of the shuttle’s backup landing sites). Given that you’ve got only one chance to land a shuttle, you might as well hand fly it in.

Like Kowalski, I genuinely want CAD software to become my "partner in exploration." Like him, I agree that the era of computer aided documentation is outdated. But whether our computers end up being creative or not, I want to communicate with them in a way that respects their abilities - and my own. And I don't think that "well stated problems" are it.

I'll close with a final thought from Mindell, this time from an interview he gave to EconTalk:

We have yet to build a system that has no human involvement. There's just human involvement displaced in space or displaced in time. Again, the coders who embed their world view and their assumptions into the machine, or any other kind of designer - every last little bracket or tire on a vehicle has the worldview of the humans who built it embedded into it. For any autonomous system, you can always find the wrapper of human activity...Otherwise the system isn't useful.

At nTopology, we know that Computer Aided Design will be an increasingly collaborative process. Our goal, then, is to integrate automation in the most useful ways possible - the ones that produce the most effective, efficient parts. I believe that keeping engineers fully in the loop is the way to do that - and am looking forward to making it happen.

On PDFs

I've written offhand things about PDFs before, but Ben Wellington is clear and straightforward in this post:

     You see, PDFs are where information goes to die, rather than to be used.

If you have something to communicate, think *really* hard about whether you're okay with it dying. This goes for *way* more than just public data, too. Product info, scientific research, industry knowledge... Put it in a PDF, and it's frozen.

This is why Gongkai AM is on GitHub. It's a weird platform for most people in R&D and engineering, but one that allows for *way* more flexibility and longevity. 

Not as hopelessly unyielding

From a piece in the New Yorker about The Ford Foundation (lightly edited on my part):

The urge to change the world is normally thwarted by a near-insurmountable barricade of obstacles: failure of imagination, failure of courage, bad governments, bad planning, incompetence, corruption, fecklessness, the laws of nations, the laws of physics, the weight of history, inertia of all sorts, psychological unsuitability on the part of the would-be changer, the resistance of people who would lose from the change, the resistance of people who would benefit from it, the seduction of activities other than world-changing, lack of practical knowledge, lack of political skill, and lack of money.

Lack of money is a stubborn obstacle, but not as hopelessly unyielding as some of the others.

The above was written in the context social justice, but much of the paradox in this article translates to business too. While lack of money can certainly screw you up, it's more common to fail because of the multitude of other factors working against you - many of which are *far* more difficult to overcome than lack of money.

I don't want to be Amazon.

GE CEO Jeff Immelt, talking with Henry Blodget:

There's a lot of people who have gotten fired thinking they're Jeff Bezos. So I don't want to be Amazon. I want to be GE.

This is right after Immelt refers to Bezos as someone he admires.

I've thought and written about corporate self awareness before (in particular with respect to Amazon and McMaster-Carr; see also the last paragraph or two of this old post about Pixar), but it's been increasingly on my mind recently. 

Knowing who you are - and having the fortitude to act accordingly - is key.

Joining nTopology

Nine months ago I had one of those random conversations where you walk away feeling thrilled to be working in an industry with such compelling, intelligent people.

I had met Bradley before then (there are only so many people working on additive manufacturing in NYC), but only in passing. In the meantime our paths had diverged somewhat. He was working hard on design software, whereas I had focused on getting industrial AM experience through developing a physical product. But our approaches to the industry had converged, and we had developed a shared enthusiasm for addressing the technological problems in AM head on. We became instant allies, and started swapping emails on a weekly basis. 

In August, when nTopology launched their private beta program, I jumped at the chance to use it in my own designs. The engineering advantages of lattice structures were immediately evident, and nTopology's rule-based approach allowed me to quickly develop designs that met my functional goals. And as I spent more time with nTopology's software - and got to know Greg, Matt, Erik, and Abhi - my enthusiasm about what they were building only grew.

Today I'm thrilled to announce that I'm joining nTopology full time, to run business operations and help direct product strategy. nTopology's team, mission, and product are all precisely what I've been looking for since I began working on additive manufacturing, and I can't wait for the work we've got ahead of us.

For posterity, here are a few thoughts about nTopology's approach towards design for additive manufacturing:

1. From the very beginning of my work in AM, it was evident that traditional CAD software would never let me design the kinds of parts I wanted. I was looking for variable density parts with targeted, anisotropic mechanical properties - things that feature-based CAD is fundamentally incapable of making. nTopology's lattice design software, on the other hand, can. 
2. As the number of beams in a lattice structure increases beyond a handful, designing by engineering intuition alone becomes totally impractical. It's important, then, to run mechanical simulations early on, and use the results to drive the design directly. nTopology let me do just that.
3. nTopology's approach towards optimization lets me, the engineer, set my own balance between manual and algorithmic design. This is key: when I intuitively know what the design should look like, I can take the reins. When I'd rather let simulation data drive, that's fine too. The engineering process is collaborative - the software is there to help, but gets out of the way when I need it to.
4. Best of all, nTopology doesn't limit me to design optimization - it lets me design new structures and forms as well. That means far more flexibility for me. No longer am I locked into design decisions artificially early in my workflow, when a lot of the effects of those decisions are unknown. nTopology gives a fluid transition from mechanical CAD to DFM, and lets me truly consider - and adjust - my design's effectiveness and efficiency throughout the process.

The nTopology team has shown incredible progress in a tiny amount of time. They've built a powerful, valuable, and intuitive engineering tool in less than a year - and have set a trajectory that points towards a paradigm shift in additive manufacturing design.

In the coming months, I'll be writing more about our company, our mission, and our design workflow. If you're an engineer, developer, or UI designer interested in working on the future of CAD, send me a note or see our job postings on AngelList. To learn more about purchasing a license of nTopology Element, get in touch with me directly here.

Murray Hill

I'm reading The Idea Factory, and this description of Bell Labs' Murray Hill facility jumped out at me:

Kelly, Buckley, and Jewett were of the mind that Bell Labs would soon become - or was already - the largest and most advanced research organization in the world. As they toured industrial labs in the United States and Europe in the mid-1930s, seeking ideas for their own project, their opinions were reinforced. They wanted the new building to reflect the Labs' lofty status and academic standing - "surroundings more suggestive of a university than a factory," in Buckley's words, but with a slight but significant difference. "No attempt has been made to achieve the character of a university campus with its separate buildings," Buckley told Jewett. "On the contrary, all buildings have been connected so as to avoid fixed geographical delineation between departments and to encourage free interchange and close contact among them." The physicists and chemists and mathematicians were not meant to avoid one another, in other words, and the research people were not meant to evade the development people.

By intention, everyone would be in one another's way. Members of the technical staff would often have both laboratories and small offices - but these might be in different corridors, therefore making it necessary to walk between the two, and all but assuring a chance encounter or two with a colleague during the commute. By the same token, the long corridor for the wing that would house many of the physics researchers was intentionally made to be seven hundred feet in length. It was so long that to look down it from one end was to see the other end disappear at a vanishing point. Traveling its length without encountering a number of acquaintances, problems, diversions, and ideas would be almost impossible. Then again, that was the point. Walking down that impossibly long tiled corridor, a scientist on his way to lunch in the Murray Hill cafeteria was like a magnet rolling past iron filings.

Sounds like my kind of place.

Why Gemba

I’ve been working a lot on the mechanics of how Gemba (my idea for a shared industrial 3D printing space in NYC) would work, and it struck me that I should probably write down why I want to do this in the first place. These are intended to be mostly personal reasons; here goes.

I like building stuff. Having a measurable output is a big motivator for me, and I find myself similarly drawn to people who are building stuff too. 

In particular, I like building stuff that’s valuable. I’m being intentionally abstract here: my blog is valuable, and so are manufactured goods, and so is the process and craft that one learns by manufacturing things, and so is the management expertise that one develops through years of working on hard problems, and so is the social capital that one accrues by being a considerate, dedicated, hardworking person. Ideally, I’d structure my life such that I can focus on one of these things and still let the others flourish; the compound value would be exponential.

I also, for purely selfish reasons, want to make an impact on long term global problems. Like any new manufacturing method, I believe that metal AM has the potential to make a positive impact on our ability to make long term valuable products (lightweight transportation systems, patient specific orthopedic implants, etc) more effectively and efficiently. And given my experiences over the past two years, I think I can play a significant role in increasing its rate of adoption and maturity.

It’s possible I could do this in a private environment - working full time on a single, proprietary solution. But in order to create a larger impact more quickly, I feel it’s important to work alongside others. I want to work in the MIT Building 20 of advanced manufacturing. I believe that my own output - and my quality of life - will be much improved as a result.

It’s no secret that New York City is no longer the center of manufacturing that it once was. But at the same time we’ve got some of the nation’s top minds in architecture, engineering, and construction, and our 3D printing community is one of the largest in the world. We’re also the geographic center of a huge network of manufacturers (large and small) that populate the I95 corridor, and we remain *the* cultural magnet for young engineers graduating from any of the top tier schools in the Northeast.

These factors - and the anecdotal evidence that myself, and people like me, want a place to work on industrial grade problems - will give Gemba NYC a robust technical pipeline and talent pool. In addition, though, New York adds a significant edge when it comes to business model and marketing leadership. We (and by we I mean a combination of companies like Makerbot and GE) have been at the forefront of a total rebranding of additive manufacturing - one which has brought a huge influx of investment, talent, and ideas. New York also has a proven track record in developing and launching just in time, direct to consumer businesses (see Warby Parker, Casper, Blue Apron, etc) that shorten supply chains and are more responsive to end user needs. Additive manufacturing will need this expertise; New York will provide it.

In short: I believe in the technology; I believe in the power of working in close proximity with others in the industry; I believe in New York City’s ability to lead technical and commercial solutions to the problems facing industrial AM.

I want to increase the success rate of industrial additive manufacturing. I think it’ll be fun, and interesting, and will benefit both myself and humanity as a whole. And in order to increase my own success rate, I want create a space where dedicated, forward thinking companies and individuals can experiment with and develop solutions to the problems facing AM today.

This will require a big effort, and I’ll need the involvement of people and companies much more experienced than myself. I’m looking forward to hearing what their interests are, and developing a space and financial model that serves us all well. If the things above resonate with you, get in touch - I’d love to chat.

What I'm working on

Ada and I got back from our honeymoon on Wednesday evening. It was really great to unplug a bit over the past month (aside from the first few days of October, I really haven't worked much this month), and between yesterday and today I'm spending a little time reprioritizing the backlog I was chewing through in September. Here are the things I'm focusing on in the next few weeks:

• An explainer post (with video!) on the practical differences between EBM and DMLS. This is something I've been meaning to do for a little while; I think it'll be a good exercise for me and useful for a *lot* of other people.
• A functional design for a titanium bike stem that implements lightweight lattice structures. I ran through some initial designs in late September, but they're not printable yet and will require at least a few days worth of design work on my end - plus help from a few others, including my friends at nTopology - before I have something that is manufacturable. Once I get there, I'll run a few prototypes and put them into service.
• A short study on surface treatment options for EBM parts. I'm looking primarily at micro machining, isotropic superfinishing, and wet blasting, and will be comparing methods on cost, aesthetics, and the resulting mechanical properties of the part. I'm doing this on the seatpost parts that I got from Addaero recently, but hope that what I learn can be applied to other parts in the future.
• An integrated seatpost + saddle frame design consisting largely of a lightweight lattice. I hinted at this recently, and have been working with Direct Dimensions to get a saddle shell modeled in a way that I can base my design off of. I'm also looking a little more into building a fully custom carbon fiber saddle shell, but that's a little further off.

I'm also thinking about a few longer term things:

• More thoughts on "optimization." As a product manager, I want tools that will help me balance quality, cost, and speed to market. I find that most design software misses the mark on this, and I'm working on a blog post that points to a better paradigm.
• Building a real product development shop in NYC - a place where people like myself can use both additive and subtractive manufacturing to build engineered products. This is something that's close to my heart, but it's also a longer term undertaking; it may be a little while.

More on all of this soon.

Guidelines for The Prepared

My weekly manufacturing newsletter, The Prepared, has grown significantly in the last few months. I had more signups in August than any month before, and I've been proud to recognize more and more of my subscribers for having done work that I've admired in in the past.

As it's matured, I've gotten a bit better about knowing what I - and my subscribers - want from it. Here are a few guidelines I use currently:

• Be focused. While I might fancy myself capable of commenting intelligently on a wide range of topics, the fact of the matter is that while people will appreciate the "manufacturing guy comments on other random subject" link, they won't love the "random guy comments on whatever he wants" link. 

• Have a voice. I'm with Joe Biden on this: No matter how well it pays, I don't want a job that doesn't allow me to be me. 

• Be pithy. I tend to pontificate, but this is a weekly email. Try to keep it short.

• Be warm. I tend to be skeptical of things I don't have personal experience, but the point of the newsletter is to connect people with interesting stuff. Where appropriate, show a little enthusiasm :)

• Differentiate yourself. I subscribe to a few great newsletters (check out Jon Russell's, Reilly Brennan's, Alexis Madrigal's, and Benedict Evans's), and will definitely repost stuff that those guys share. But ultimately it's good for me to have my own niche, and defining myself in opposition to them helps make The Prepared better and more useful to my subscribers.

• Don't stress the format. The categories are useful for organization, but they really don't matter that much.

• Attribute links where it makes sense. This is a tricky one, especially because my workflow (which is 90% Pocket, 10% IFTTT+Gmail) doesn't make it easy for me to remember who sent me what. As a result this ends up being mostly driven by practical constraints, like whether or not the person who sent it could use a shout out, and whether or not they have a web presence that I can link to, and how well publicized the thing they sent me was. Not exactly a science, but I try.

• This is a weekly email, but the actual day I send it out doesn't really matter. Some people may feel differently, but my rule is that I need to send it "sometime in the weekend," and I define "weekend" liberally.