I missed my self-imposed deadline for the monthly newsletter, so I’ll have to pick up the pace. A combination of travel, work, and vacation have conspired against me. I’m in the hole two for this month. For consistency I’ll call this one the June newsletter and the next one will be July (hopefully the right month).
I just came back from a vacation where I was lucky enough to have access to a boat – a pontoon boat. It got me thinking about what is great and what as awful about that craft and how it might be made so we keep the great and mitigate the awful. Perhaps the subject of a future design study. When my workload eases I might put some effort into trying to improve on the pontoon boat design and see about a little pretotyping (something you’re already well versed on from the previous newsletter).
In the previous edition we talked about finishing a design. The next logical step is to have the design built. Unfortunately, SES is not in a position to do that yet, so I am in the process of procuring the services of a fabrication company to make my vision reality. That can be nerve-racking because at some point you lose control over the design to people you know very little about. We all encounter this at some point. Developing a technique for evaluating your partners – especially when executing your vision – is critically important as is how you work with them. That is the subject for this edition.
As you start expanding your capabilities, you will need to create alliances with people that know more than you do. As much as it pains a self-proclaimed generalist to say, I can’t do everything. It might be there’s just not enough of me, I don’t have the equipment, I don’t have the skill, I don’t have the experience, or the reputation. Whatever the reason, at some point you will have to partner with people that are not completely under your control.
This is extremely scary for me as I like to control as much as possible. When I have a vision for a project, it is very well defined in my head, but I know that however much time and effort I take communicating this vision, someone else will interpret the vision differently, purely because they have a different perspective based on skills, education, and experience. There is no way to capture everything going on in your head on a purchase order, drawings, specification, etc. And it’s even harder to enforce penalties when your vision is butchered by someone else. The only option is to partner with someone you trust to do the right thing. Someone that can capture your vision in their own way by asking the right questions, have the appropriate experience, or just getting lucky. Extremely scary. And how do you find them and work with them?
There are different types of partnerships. They range from partners that deliver well defined products to general assistance. The former is the least difficult to manage, though often the least important. This would include buying commercially available components, having a standard service provided, etc. It’s the type of partnership that most don’t consider a partnership – just a transaction. The other end is where the risk and opportunity really go up.
There are few things as difficult as choosing your partners. I find the whole thing daunting. The process is poorly defined and the potential consequences high (both good and bad). Everyone is trying to sell their services and separating the truth from the chaff can be difficult. You have to balance your approach between two extremes – trust nothing they say or believe every claim. Even after you’ve got a handle on how much to trust their claims, you have to know how to work with them.
When doing oddball designs and analyses for something that will only be performed or built once you encounter the need for partners that provide unique services – the types of partnerships that require real thought and attention. Partnerships like this require a thorough understanding of risk and trust. For the remainder of this newsletter, I’m going to focus on these high stakes partnerships as they are the most applicable to prototype engineering.
There are two broad ways you can think about evaluating a partner: do you trust their abilities, and do you have confidence that your trust is well placed. As an example, it may be clear that a company can make a widget, but you may not know them well enough to know whether they can do it dependably or to your liking.
We’ll step through determining how much you trust their abilities (trusting their claims) and how confident you are that you’ve got it right (verifying your trust). We’ll also talk in some detail about my favorite approach for informing both of those topics – the visit.
The balance between trusting every marketing claim and only believing the results of work is one that will have to be managed. Going the former route with no other context is very dangerous. Only believing results can be either impossible, impractical, or extremely costly. In the end, you need to have the appropriate amount of trust for the responsibilities you intend to assign your partner, which will determine how you go about determining your level of trust.
The most obvious and simplest approach is to review readily accessible information. We all do it. We go to the website and delve through their certifications, bios, past projects, etc. If you’ve been doing this for a while it’s easy to identify overblown claims. This will give you a baseline of what you expect from the company, but without additional verification, it’s unlikely you would stop here. The next level of establishing your level of trust involves talking with an actual person to determine consistency, looking at reviews, and talking to others that have worked with them before. For simpler projects, you may get enough information to know what they are technically capable without having to go much further. But if you want to know more, you have to go to for a visit.
Visits are complex topics, so I have an entire section devoted to the subject below. In summary, the primary purpose of the visit is to verify trust as well as establishing a relationship, but it can be used as a tool to determine the appropriate level of trust. When readily available information is not sufficiently detailed to establish the specific capability you are looking for or you don’t want to say exactly what you are doing, putting eyes on the facility is the only way to close the loop on whether their claims are worthy of your trust.
This is where the risk aspects of the partnership comes to play. The amount of effort put into this step should be proportional to the importance of the results from the relationship. If there is little consequence to them betraying your trust (they’re flaky, don’t do good work, incompetent), you can almost skip this step and move forward without incurring the overhead. On the other hand, if the results being “right” are important, verifying your trust is also important.
At the most basic level, you can verify trust during the contracting or proposal phase by requiring specific documentation be provided. That could cover the quality programs, procedures, ability to do schedule planning, etc. Comparing their submittals with your expectations is a good barometer on whether your trust is well placed. This is a pretty standard approach for verification, but I would argue that for most work of any value, you need more.
For that comes the site visit…
When you need additional assurance that trust is well founded, I have few tools more valuable than visiting the partner at their facility. This goes for partners doing analysis all the way to complex mechanical and electrical components. It seems strange for an engineer that spends 80% of his time working remotely to put such emphasis on an in-person visit, but here we are. I’m not talking about camping out at their facility – I’m talking about a few hours with your eyes and ears open.
When I do a site visit, these are the items I’m trying to glean. I’ve put them in order of importance for your convenience.
Note that I didn’t talk a lot about verifying paperwork, QA programs, shop schedules, equipment maintenance logs, etc. Sometimes I’ll include that in a site visit, but it’s only to get access to the information above. Those things will be part of the procurement process. Wasting time at the site with this sort of minutia takes valuable eyes and ears open time.
Now that you’ve vetted someone and have the appropriate amount of trust and confidence in their capabilities, it’s time to get some work done. The first thing you should establish is a clear demarcation of responsibilities. As Admiral Rickover said,
“Unless you can point your finger at the man who is responsible when something goes wrong, then you have never had anyone really responsible.”
That isn’t the same a “blame”. Responsibility is merely who is charged with fixing a problem. Things can happen that are out of anyone’s control or caused by someone else. This is independent of who is responsible for fixing it. This can be a contentious aspect to partnership, but the relationship can be even more contentious if something happens and responsibility has not been assigned.
Even in the best working relationships, clearly defining responsibility is critical. With a very good, long term partner, the definition may be very broad, but well defined and documented. Something as simple as a scope statement that defines the boundaries for responsibilities may be enough. For a less well established relationship, responsibilities would be codified in the contract as well as remedies to be used. Regardless of the partnership relationship, the responsibilities must be documented.
Communication is the most critical aspect of a partnership. Everyone thinks differently, so every idea is translated between “languages”. Can you both envision the same goals when you speak different dialects? Often this is something you need to figure out through trial and error. And in our business failed trials can be extremely expensive. Communication can be categorized as either informal or formal. The efficiency of informal communication means that often most of the information is transferred in this manner. That can be risky when there is high risk or a new relationship. That’s where formal documentation comes in. It can be slow and cumbersome, and even with your best efforts incomplete. But it’s almost always necessary. We’ll talk about both below.
We would like to be able to rely on chatting over the problem, coming to a solution, and just making it happen without the hassle of writing anything down. It’s the way we want to work, and when we can get things done this way it’s extremely satisfying. The exact opposite of the “Office Space” mentality where you feel like you’re endlessly doing pointless paperwork for no product.
But there is high risk here. Even with the best of intentions people mis-understand each other and the wrong thing is done. The quality of these types of communications is heavily based on personalities, experiences, environment, etc. It is hard to manage and control informal communications.
Even though there is risk, we cannot ignore the value of informal communications. They serve a very real technical purpose – to establish the intent of the formal communications, either as a predecessor to updates or as a supplement. Beyond the technical merits of informal communication are the merits of establishing a relationship with the partner that make working together easier. That alone makes informal communications and how they are approached very valuable.
written down, both partners have agreed to, and is readily available to both parties. This includes contracts, specifications, procedures, drawings, notes, etc. The level of formal agreement varies between the types of documents and relationship, but we won’t delve into those details. I’m also not going to delve into details about generating these documents as I don’t have enough hours in my life. I don’t think anyone would argue (at least anyone I want to hang out with) that generating these documents is “fun”. But it can be rewarding to see the results of your brain mashup in an organized fashion.
The most obvious reason for producing formal documents is to control the results of a partnership. The level of control required will define the minimum amount of documentation. Documentation can be roughly segregated into process paperwork and product paperwork. The first is the most tedious to all engineers and outlines how the partnership is going to work. How payment is made, how to communicate, how to assign responsibilities, etc. This information is mostly contained in a contract or partially in a procurement specification. The second is the more interesting paperwork. It defines what the partnership is working towards. What is getting made, what is the quantity, what is the timeframe, etc. Dependent on the “what”, this is best documented in the procurement specification, drawings, models, sketches… The list is endless. Both types of documents are important, and the balance between them will vary based on many factors including the type of partnership, type of product, and history between partners.
The less commonly thought of reason to produce the formal documents is to improve your understanding of the partnership and product. By taking the time to develop the documentation, it forces a more structured approach than what was going on in your head. At least for me, I am forced to translate scattered thoughts into coherent words and drawings. No small feat, but I always learn something about what I expect from the partnership, what I expect from the design, and what I expect from myself.
All good things must come to an end. Sometimes bad things too. There are many reasons to dissolve a partnership. In some cases it just isn’t working out to nobody’s fault. Other times there have been negative results. In either case there is little value in “burning your bridges” on the way out. Even if the partner really messed things up, the best thing to do is be professional and transparent as to why you will no longer be working with them. And there will be some cases where you think the industry needs to be aware of a problem. As an engineer you have an ethical obligation to publicize professional incompetence, but you do not have the right to smear or libel. That balance can be tricky, but the best way to go about it is similar to what I tell my children. “Don’t attack people, only ideas”. Similarly, “Don’t attack partners, only results.” If you are generally just dissatisfied with how the partnership went, but they didn’t do anything wrong, publicly disparaging them as an engineer is not ethical. On the other hand, if someone asks for your opinion on working with the partner, you should feel free to be honest after you note how effectively they completed the work.
This newsletter was very hard to write. Much like putting together formal documentation, once I started writing down my mind mash, I learned a lot about what I’m actually thinking when I evaluate and work with other people. I by no means got it all down on paper and had to cut a lot of it out just to make this newsletter of a reasonable length!
If I can leave you with just a few thoughts I would summarize them like this:
I have an aphorism today that has nothing to do with the newsletter – because I saw something that bothered me. I was surfing professional social media sites and stumbled on a discussion about whether you should work long hours to “get ahead” or prioritize your personal life. That’s a subject in itself, but the responses that concerned me were those that thought working extra hard in a job they didn’t enjoy was worthwhile because the job was a “stepping stone”. That implies that if you take on some work you don’t like you will be rewarded in the future. Like your career is a zero sum game that must be balanced with misery to have reward.
Perhaps I’m being too idealistic, but I don’t think I ever want to take a job on the basis of it being a “stepping stone”. I take a job because I’m interested in the work, it will teach me something I can use, or I believe that the work will result in the better good. I don’t need someone to give me a “stepping stone” – I’ll build my own, thank you very much!
Build your stepping stones instead of expecting a job to provide them.