3D Printing, Selective Recycling, and Near-Infinite Reusability


Traditional manufacturing in its simplest form involves taking raw materials and transforming them through one or more processes into finished products. One such process is the taking of some large volume of a raw material and stripping it down into a single part. Hundreds or thousands of such parts are then combined and result in things you use every day be that your car, the gas pump, the baby stroller, your office door, or any one of the hundreds of millions of products available around the world. This particular process, known as Subtractive Manufacturing, results in billions of tons of waste annually, has enormous capital costs, and racks up potentially trillions in externalized costs such as the environmental effects of over-extracting through mining and other extraction processes.

In contrast to Subtractive Manufacturing we have Additive Manufacturing, more commonly known as 3D Printing, or the building up of parts from raw materials, literally adding layers of raw material one upon the other to create a part. Ask someone, “What is 3D Printing?” and most people will answer with a story of seeing some plastic toy being built up over a bit of time at some consumer store demo or on YouTube. What they aren’t seeing are the large-scale commercial printers that are capable of printing full-size car, truck, and construction equipment bodies; real estate “parts” such as modular rooms and even entire houses; and so on.

The many impacts of the outputs of 3D Printing are discussed quite regularly today, whether those are conversations on the reduction or elimination in tens of thousands (and more likely millions, over time) of manufacturing jobs, or the ability to have nearly anything custom-built – for enough money of course. Meanwhile the discussion of inputs largely revolves around the fraction of raw materials required and the near-zero absence of materials waste. What’s often left out of the latter conversation is the idea that, if one can build a part up by layering raw materials on top of one another, one can reduce a part to its raw materials with surprisingly similar results.

Modern recycling processes, known collectively as Selective Recycling, are focused on just that. Armed with the latest in sorting and “plucking” systems, materials identification algorithms, and chemical processes, commercial “recovery plants” are advancing to a state where in some cases nearly all raw material can be recaptured from those gadgets we return in exchange for the latest hit item, or from that industrial machine that has reached its end-of-life and is being replaced with a more advanced system.

While some materials are still at low recovery rates versus others, for example only roughly 60% of iron can be recovered through advanced recycling processes while as much as of 99.9% of copper can be recovered, what happens as these advances continue to encompass more of our periodic table of elements?

What happens in as we approach a near-equilibrium state where we recover nearly all of the raw materials used in our production of… anything? What will become of the materials extraction industry in that time? What will our approaches to waste and to recycling transform into? What of our concepts of the retail store, of online shopping, or industrial equipment sales when we are able to simply print whatever it is we want or need? How about the effects on the shipping industry?

What becomes of our thoughts on the value of a thing when scarcity is decimated?

Like the impact that SpaceX’s approach to rockets is having on the space industry, the impact of this combination of Additive Manufacturing and Selective Recycling will be monumentally far-reaching. If you’re interested in exploring the significance of these transformational technologies further you can follow me here, on Twitter, or on LinkedIn as I scout ahead into our abundant and amazing future.


Additional reading on recent advances in recycling technology

Sandra R. Mueller, Patrick A. Wäger, David A. Turner, Peter J. Shaw, Ian D. Williams, A framework for evaluating the accessibility of raw materials from end-of-life products and the Earth’s crust, In Waste Management, Volume 68, 2017, Pages 534-546, ISSN 0956-053X, https://doi.org/10.1016/j.wasman.2017.05.043

Tianzu Yang, Pengchun Zhu, Weifeng Liu, Lin Chen, Duchao Zhang, Recovery of tin from metal powders of waste printed circuit boards, In Waste Management, Volume 68, 2017, Pages 449-457, ISSN 0956-053X, https://doi.org/10.1016/j.wasman.2017.06.019

Zhi-Yuan Zhang, Fu-Shen Zhang, TianQi Yao, An environmentally friendly ball milling process for recovery of valuable metals from e-waste scraps, In Waste Management, Volume 68, 2017, Pages 490-497, ISSN 0956-053X, https://doi.org/10.1016/j.wasman.2017.07.029

Bowyer, J.; Bratkovich, S.; Fernholz, K.; Frank, M.; Groot, H.; Howe, J.; Pepke, E. Understanding Steel Recovery and Recycling Rates and Limitations to Recycling; Dovetail Partners Inc.: Minneapolis, MN, USA, 2015; pp. 1–12.

1 easy trick to scaling your business as a Solution Provider


You’re a business owner, head of Sales, the leader of a Systems Engineering (SE) division, or maybe a Systems Engineer yourself, and no matter what you do the team always seems to be too busy with billable work to deliver great documentation to your customers. The first part of the sentence, that you’re all too busy, is a great problem to have – keep rolling in that revenue! The last part, however, is a death sentence. Whether it’s a scoping document, Statement of Work, design guide, implementation plan, or even a Bill of Materials I’ve seen too many SEs and too many SE teams burned out by, and several value added resellers (VARs) get crushed because of, poor customer documentation or worse – none at all.

Whether we’re talking about a rough scope for a bid, technical bits of a Sales proposal or just part of the final implementation sign-off, delivering documentation to your customer is a big differentiator. Give them low-quality documents ,or no docs at all, and you risk spending hours or more of non-billable time – because if they have any wits about them they’ll argue it’s your problem for never documenting your work – on a reassessment of their environment\systems\configurations in the future. Not to mention the impact this tends to have on customer relationships. Providing your customers with high-quality deliverables, on the other hand, might at first sound like you’re giving away the keys to the kingdom. What you’re really doing is showing that you’re in this together, you’re working from a place of mutual trust, and they can count on you to provide absolute top-notch effort.

Generating high-quality documentation can seem like a daunting task at first but the value is almost immeasurable. The real “1 easy trick” is to change your frame of mind about it. Instead of viewing documentation as an afterthought at best, or a “crap waste of time” at worst, you need to truly believe in the power of documentation. Understand that documentation can and should be created first in any project. And then act that way.

The “1 easy trick” really is that easy, so I’ll say it another way: stop trying to jam documentation work in at the end of your projects and start launching your projects from documentation. I’ll share a real example from my past that highlights the power of documentation as a proactive tool. Names have been changed to maintain customer confidentiality.

The power of documentation

A customer opportunity came up at ACME Corporation to provide both a physical office migration and an email server migration from an on-premises solution to Microsoft Office 365. Several area IT solution provider Sales teams had approached ACME with very simple proposals, none more than a few pages long. Just enough to “show up and throw up” at the 2nd or 3rd meeting and talk about “how standard and easy these types of jobs are, no sweat, when do you want to get started?” Whether any of those Sales teams did everything else right or not, none had won the trust of Bob, ACME’s VP of IT, because, and I quote, “nobody has taken the time to actually show me how the project will be executed. So forgive me, I appreciate the meal, but I hope you guys aren’t just going to show me a stock proposal and a quote as soon as we’ve finished eating.”

It was at a Friday lunch meeting with Bob that he said this. I looked over to my sales counterpart Jim and I shot him my “I’ve got this” look. He changed whatever he was going to say to, “Sean, you ran IT for a similar-size shop a few years back. What would make you comfortable if you had the same project fall in your lap?”

“Bob, like Jim said I’ve been in your seat in a past life. Maybe I’m reading into things too much, but I’ve made the mistake of trusting a solution provider too much, too, and so I think I understand where your concern comes from. If I come back to you Monday morning with a detailed plan for each of these moves, and – assuming you remember our rates – can Jim follow-up with you in the afternoon to talk about sign-off and a start date?”

Long story short, I worked with my manager to shift my last meeting for the day off to another engineer not so I could head home early on a Friday, but so I could document exactly how I intended to execute both the physical migration and the email system migration, from the high-level all the way down to the individual device and user. I showed up at the ACME offices on Monday morning, asked Bob for 15 minutes of his time to review the plans with me, and called Jim on my way back to the office to let him know Bob was ready to deal.

How did we scale to that point?

The answer is a simple one and has two parts. First, a predecessor had shifted the company’s approach to project management the point that every time Sales went to close a deal they started the close with a documentation plan. All of the engineers, myself included, were trained to understand that if a rep said they were planning to close a deal tomorrow it meant “get started on the ‘detailed design document’ and don’t sleep until it’s finished because we need it for tomorrow’s meeting”. Second, we didn’t believe in “light” or “high-level” templates, even for proposals, and the business invested the time in creating extraordinarily detailed templates. Every proposal started as a 20+ page form in Microsoft Word with an executive summary, space for several diagrams of the current state and the future state, and then a plethora of numbered lists, bullet lists, form fields, and tables where we would fill in the specific plan, in exacting detail, of how we would go from “current” to “future”. In this case I’d used our “data center move” template and our “email migration” template. I had to make many assumptions while filling out both documents, but assumptions can be changed as simply as “Find and Replace” in Word and other tools.

Not having a plan at all, however, would have lumped us in with everybody else.

The best part? Doing all of this work up front not only meant much greater chance of success in our Sales team, but also that much less work for me! Why? Because I had laid out all of the steps ahead of time, all I had to do on the day of the migrations was show up and go through my checklist! Many times, the person drawing up the design wouldn’t be the person executing the work, and we used this as a constant test of our planning capabilities. The company believed in the power of documentation so much that we all bet our reputations on it. This level of documentation was also useful when navigating those challenging situations where something wasn’t working right and we had an irate customer on our hands. Any Support Analyst would start by stepping through the docs to validate whether the configuration had changed since the last time any of us did any work, and then either get the OK from the customer to revert the change or to adjust other parts, of whatever system they were dealing with, in order to get things running. And talk about continuity in our approach: if they did make a change, they would first document a rollback plan, again using a template, make the change, and then update the design with the new configuration before closing the ticket. If anything bad happened in the future, we were again covered, as any other Engineer or Analyst could step through the docs and see step-by-step what the correct configuration was supposed to be.

For more information on scaling your documentation capabilities from “average” to “amazing”, start with the references below. You’ll need to get comfortable with creating templates, forms, macros, and other tools available in Microsoft Office and other productivity suites. Whatever tools and techniques you ultimately land on, if you’re looking to scale your capabilities as an individual contributor or drive scale across your team, creating solid documentation up front and believing in the power of documentation is critical to your success.