When working with peers who can write software you should be mindful of how you ask for help requiring their expertise. Because you are juggling a professional and personal interaction simultaneously, it’s easy for expectations to get out of alignment. I’ve observed two main mindsets when people approach this type of situation: treating the interaction as you would with an architect and as you would with a contractor.
When working with architects, you present a problem that you want to solve and ask for their expertise in how to design a solution. You work together to come to an agreement on the attributes of a good solution. You’ll specify the look and feel that you are hoping to accomplish and other basic requirements, but after that you trust the architects to use their expertise to come back with a proposal using whichever tools or inspiration their team sees fit.
You expect to give the architects breathing room until they have something for you to react to. Once there is a proposal, you can iterate on the details. In this mindset, you are more interested in setting the overall direction of the project than in managing the particulars of how it gets accomplished.
When working with contractors, you present a concrete specification of what you need built (e.g. providing a floorplan and a bill of materials). The relationship is more transactional. You pay the contractor and they are expected to deliver exactly what you ask for. Contractors are also expected to do work the way you ask for it to be done, while adhering to your budget and timeline. In other words, you can specify which tools they use and the brands of the materials. It’s a less collaborative process than you have with an architect.
Contractors bring expertise in their speed of execution. Taking a project to production usually requires both architects and contractors.
(Here are some of tips on how to be most efficient when working with freelance developers.)
When building physical products, most people defer to the expert’s judgement. It’s natural for someone to say, “I don’t know which kind of plastic we should use when manufacturing the part we need. I’ll defer to you.” There is no presumption that you should prescribe the type of injection molding if you are not the group expert.
But, when working with software, people often feel comfortable asking for specific tools to be used, even when they are not the subject matter expert. You’ll often hear people say, “I need a Wordpress site that can do XYZ.” It’s easy to want to specify the tools that you have heard of, but these interactions suggest that you are not actually interested in working with a peer on equal footing. In effect, you are asking for a peer to perform a specific task that you either don’t know how to do yourself or don’t have time to do yourself.
Top-down dirctives indicate that certain team members have more ownership of the project; others are simply working to carry out their directions. This may be appropriate, but you should be sure that this is the dynamic you want.
As peers, it’s natural to assume that a project is going to be collaborative. If that’s not what you have in mind, you need to clearly communicate that upfront. Misalignment will likely lead to resentment in both directions and can potentially harm your personal relationships.
Collaboration requires open dialogue. If you intend to disregard the advice of your group expert, you should explicitly articulate your reasons. But, in the vast majority of cases, you should probably respect to your group expert’s preference. Afterall, that’s why you wanted to have that person on your team. Further, your group expert is likely able to see implications of seemingly small decisions that others with less experience won’t be taking into consideration. This will lead to higher productivity and improved morale.
My recommendation is to be intentional about the ways in which you interact. If you don’t like the dynamic, you should speak up. If you are asking for help, try to be empathetic to how you would want the dynamic if you were on the other side. Most likely if you were the one bringing technical skills to the table in a peer setting, you would want to be treated as an architect who is co-creating, rather than as a contractor being tasked to accomplish something.
P.S. Here’s an academic paper about the implications of having different mindsets when learning and working together.