Since the introduction of CAD programs, the usage of computers has taken over the engineering world. Old-timey rooms full of drafters, decked out in white shirts and ties, furiously sliding rulers simply don’t exist anymore. Other parts of the engineering world have similarly changed. Document control is taken over by PDM software, project management tools for things like gantt charts are a dime a dozen. A heavy reliance on technology is there, but most engineering teams are not making the most of this digital world. In an engineering team, the individual roles and how they interact have evolved, but the team make-up itself hasn’t. I believe it is time to rethink engineering teams, and the addition of a developer role.
Value of a Developer
The big question when deciding to add a developer to a team is: what value do they bring. A developer isn’t going to be right for every team, so it is good to understand what ROI they bring. The benefits that developers bring can be split into three categories; reducing engineering work, reducing costs, and solving the previously impossible challenges.
The most obvious benefit is directly saving time on daily engineering tasks. If the time a developer can save an individual engineer is known, the cost analysis is simple. For example, we start by assuming that a developer is paid similarly to an engineer. If a developer is able to save an engineer 10% of their time, it would take a team of 10 engineers for the developer to be valuable. But if you look at it another way, one developer can replace an engineer in a team size of 10. For a team size of 20, that developer gains the same benefit as hiring 2 additional engineers. As the size of an engineering team grows, the potential value that a developer can bring grows to the point where it should be a necessity. A 100+ person engineering team should absolutely have a software developer in the mix.
The time cost analysis is a simplistic view of what a developer brings. It assumes that all work a developer can provide is directly reducing that of an engineer’s. But a developer has the potential to provide value in a way that an engineer can’t. Improvements such as error reduction, reduced lead times, more accurate quotes, and reduced waste, are all common when introducing new software technologies to a company. Look at not just the value of an engineer, but also the money they can cost a business.
"Any sufficiently advanced technology is indistinguishable from magic" - Clarke's 3rd Law
Finally, a developer can bring unknown value through their black magic. It might not be real magic, but it can feel that way. When I work on design automation, I can create features that a designer would never be able to. Designs that would otherwise be impossible can add an unknown amount of value to a business. Likewise, work that would have been too time consuming can be done by a program. Engineers saying "Nah that would take too long" isn't an excuse anymore.
Hiring a developer
You see the benefit of a developer, now what? If you’re on the fence about hiring a developer, one option is to hire a consultant. The per hour rate of a consultant is going to be much higher than an employee, but the benefit is that 1) they will already be an expert and not require training, 2) there is no longer term commitment. But this does involve finding an expert. Finding a consultant who does not have the experience and expertise in this specific instance is going to give false numbers. The person you got to do your website is going to take 100x longer than the person who has 10 years experience working with CAD integrations.
Hiring a consultant gives an additional benefit, they know what can be automated. Every time I talk to engineers and discuss their challenges, many of their problems end up being easily fixed. Knowing a better solution could exist is half the battle. An engineer spends the whole day problem solving, so finding a workable solution is usually what they do. But they don’t always have the expertise to build a proper solution.
You've decided to hire a developer full time to join your team. How do you find the right one? You probably want one who knows your CAD system, who has engineering knowledge, and 10 years experience. Too bad, that person is happily employed elsewhere. But I'll let you in on a secret: developers can be trained. A developer needs to learn more than just new technologies, but also engineering industry knowledge. Instead of looking for a developer that is already perfect, look for one with good potential. Developers that are keen to solve problems, be creative, and dive deep into a subject.
Stay tuned for a future piece on training developers...
How to work with a developer
Now that you’ve hired a developer, the question is, what do you do with them? A developer on the team is going to be a new challenge for an manager. Their tasks, timelines, needs, and knowledge are all going to be different.
Treating a developer as a team member is important. If your company does daily standups, weekly or monthly team updates, include the developer in those meetings! They will be able to spot issues that they can solve. Not every project will be delivered to them by their manager. Treating a developer as a separate department, or external resource puts up unnecessary walls. A developer should always have direct access to the other team members that they are there to benefit. Put them in the same room as the engineers. Having to go through a chain of command for everything is a sure fire way to reduce the usefulness of your developer, and potentially frustrate them.
Remember that there are now two perspectives to every problem: the developer way, and the engineer way. It is crucial to respect that a developer will make the correct decisions within their domain. Should the app be Java or Javascript? If you need to ask, then leave it to the developer. Another challenge to deal with is two sets of projects. The engineers will be working on some cool new bracket, while your developer workers on a optimized shelf tool. These two projects will have different timelines and hurdles. Finally, they'll also require different forms of feedback. Your developer doesn't have a customer, for them to continually improve, you need to give them constructive feedback. Their success won't always be apparent to them.
Caden’s Musings - Onshape
I’ve been working a lot with Onshape and FeatureScript to do design automation. In a recent project, I had to make a model of a part that would be used in an automation. But modeling the part I ran into some issues. I had problems such as needing a plane offset from the tangent of a line relative to how another line was offset from an axis. An experienced designer might have had a clever way to solve these problems, but I am not an experienced designer. Luckily, I had FeatureScript at my disposal. In less than 5 minutes I had a feature whipped up that could do exactly what I needed. In this case, I was making up for my own shortcomings in CAD design experience, but it got me thinking about how valuable a developer could be on an engineering team.
For large automations, which make up the majority of my work, the ROI is obvious. Saving thousands and thousands of engineering hours is a no brainer, and traditionally that was the minimum to make something worth automating. Doing design automation for most CAD programs, the development time for a feature is huge. But FeatureScript is different, the effort to create a valuable feature is astronomically less, so smaller features can be worth creating. This is my motivation behind the thought that engineering teams should shift to include a developer. FeatureScript is a big change in the industry, and will be a catalyst for changing how engineering teams are created.