Paul Weakley: The Art of Engineering
Paul Weakley is a Partner with PhoenixTeam, Arlington, Va., a women-owned small business that provides mortgage technology services to improve the home loan experience for borrowers and help financial institutions, technology providers and government agencies achieve their desired outcomes. For more information, visit www.phoenixoutcomes.com.
On different occasions I have been asked to describe mortgage technology software engineers – how they think and how best to interact with them. It is an interesting question because every engineer is different from backgrounds to experiences, even different thought processes. Yet, I understood that people who asked this question wanted to interact more effectively with the engineering teams.
So, just how do architects, stakeholders, product owners, designers and users better interact with a mortgage software engineer?
The Creative Space
The first step is to understand what an engineer is and does. Think of the engineer like an artist, because software development is an art. It requires a significant blend of skill and creativity to create even simple applications. No artist will accept someone telling them how to use a paintbrush or even what paintbrush to use and you certainly cannot step in and try to put paint on their canvas. The same is true on an engineering team; there is an understanding and an agreement of how they will work together on the software. There is a balance between the number of artists and the size of the canvas that directly relates to how the art – software – is built.
Furthermore, do you notice how engineers do not gravitate towards prototyping, or drafts? Their first approach is the software they are writing will be production quality. Of course, an artist would never start a painting thinking it is worthless, yet some artists will sketch, refine, then apply color to the artwork. It is a way of iterating through a design to validate along the way. Engineering as a practice has not moved into this space yet. We are still building sculptures or treating our creations like we are the notable artist and teacher Bob Ross. It will always be perfect; we will build it right the first time and we certainly never write defects – code works as written.
However, this does not mean that you are at the mercy of the artist. Art that only has value to the artist is never displayed and never enjoyed by others. The same is true for software.
The best application that never makes it to production is still useless. Therefore, we work with these engineers in a way to bring value to the software they create. Stakeholders are going to put this art in their gallery so it must fit with the theme and requirements. Product owners need to sell the art to the stakeholders. Users will view the art, but if they do not like it, they will not purchase it or return for more. Architects are the coordinators making sure that all the artwork creates a collection that works cohesively for everyone involved: engineers, stakeholders, and users.
Software has been generally developed using firm requirements and strict acceptance criteria so that the parties involved get what they are asking for from the engineers. Gaps in the requirements leave space for the creative side of the artist, and it is important to remember that engineers are artists and creativity is their nature. When they have the freedom to express themselves, they will create a masterpiece that will be appreciated and effective. However, if you limit engineers, it can ruin the primary reason you hired them in the first place – their creativity. The best solutions and the best software come from a co-creation space where everyone involved is working together to create that masterpiece.
Instead, approach the conversation from a “what matters” perspective. Engineers get burnt out from creating and recreating software and hearing all the things people do not like about their work. It is fine when it has only been a small effort, but after months or years of building the “wrong” thing, the spark of creativity will fade.
Validating the value of the engineering work before critiquing can improve the process. Engineers will retain their passion knowing they are creating something that will have value for others and will be more understanding of the needs (hard requirements) and wants of the product. In the gaps, the space where creativity thrives, you will find that your engineering teams will surprise you with their talent. They may even bring value to the client that no one else saw previously. Artists do not get free reign; they are always restricted to a canvas, but you can shape the artwork by fostering creativity and focusing it on what matters most to those that want the artwork.
(Views expressed in this article do not necessarily reflect policy of the Mortgage Bankers Association, nor do they connote an MBA endorsement of a specific company, product or service. MBA NewsLink welcomes your submissions. Inquiries can be sent to Mike Sorohan, editor, at firstname.lastname@example.org; or Michael Tucker, editorial manager, at email@example.com.)