In today’s corporate world it is likely you have had to work with a Software Development Team to complete a project or make an improvement for your team at some point. Over the years I have learned some things that tend to create a more successful outcome.
The Problem with Silos
In businesses there is a tendency to silo ourselves in our departments and the people we work with most often. This makes sense as our team members are the people with which we share our wins, successes, frustrations, problems, and failures. As such we tend to only see OUR side of things and are not aware of what is going on in other departments.
For example, let us say we are an operations manager at a company that sells products direct-to-consumer from our website. We might feel the development team is taking too long to finish our project that will decrease costs per unit by 3%. This is a great project and can have a huge impact. However, what we don’t see is the development team has been working overtime in order to fix a problem where some customers are unable to finish their order. They aren’t intentionally taking longer, they simply don’t have the resources for their current workload. Pointing the finger at the development team is the wrong move.
Another temptation will be to start pointing out the ways they are doing things wrong or how they could be more efficient. This would also be a mistake as we don’t have any knowledge of why they are operating the way they are. In addition, it is also likely they have suggestions of their own for us. However, we would be both equally wrong in assuming we know everything about why things are done a certain way in another department.
Another thing to consider is that dev teams are generally at the mercy of other departments. It is usually the executives that decide what project gets chosen over another. Dev teams don’t often get to choose what things they get to work on.
The Solution
Make the development team part of the solution
Don’t go in with a predetermined way you want it done. Go in with a result you want to achieve and let them figure out the technology and resources to make it happen. You can course correct if they don’t create what you want on the first pass. Communicate clearly what you want. Be as specific as you can beforehand and make a detailed document. If you aren’t exactly sure what you are looking for then be up front about it and let them know it may require some back and forth. (They might have some good ideas on things you had not thought of)
I made this exact mistake several years back. I have always liked technology and software and have dabbled in it as a hobby for many years. I also have degrees in Information Systems. Sometimes this is a benefit as it helps me understand how certain things work and I don’t need an “IT translator”. However, this can also get me into trouble sometimes as it can make me just knowledgeable enough to be dangerous. I remember one instance when I needed a new report to aggregate all items sold worldwide of a particular product type even though these would all be different SKUs. Different countries had different labels and because of that were tracked as different saleable SKUs. I wanted to know the global demand for all SKUs of the same type. I had already designed how this would work. They would just have to create code that could “break down” the code into its components to determine what the “base SKU” was. Or so I thought. After a few days the developer came to me frustrated. They were having a hard time making my suggested way of doing it work, because many of the SKUs did not follow the format for one reason or another. They proposed just making a table in the database for each SKU with an assignment to a base code. I told him that was a great idea and the developer had this done in a couple of hours. Had I simply given my required needs I would have received a working report the same day and the developer would have been able to use that time on a different request.
Check in periodically
Setting up a quick 15 min catch up on a regular basis can help with clarifications. How often you do this will depend on what your project is. For example if the project is expected to be 6 months you don’t want a daily check in. A weekly or every other week would be more appropriate. Once you have established the frequency don’t be afraid to re-evaluate if it is too often or not often enough. If you find that your meetings rarely have anything new to discuss, consider making them less frequent. Conversely, if there are a lot of questions in between meetings consider making them more frequent, but don’t be overbearing.
Encourage questions
The last thing either team wants is a project that will not solve the problem. Make sure to let the development team know you are open to questions. As part of that, here are a few things to be aware of:
- There are no bad questions. Remember the goal is to make sure the dev team understands what you need so they can provide the solution. You should be more invested in that than any annoyance from a repeat or question you think didn’t need to be asked.
- Don’t try and guess the end of their questions. Let them get their thoughts out. Sometimes it may take some pauses to fully communicate their thoughts.
- Make sure someone (or an LLM like Google’s Gemini, Windows’ Copilot, or OpenAI’s ChatGPT) creates notes and summarizes the meeting. Memories fade and if there are good notes of what happened it reduces the quantity of repeat questions.
Be gracious and thankful
This should go without saying, but I have seen it forgotten and overlooked on occasion. It is important to recognize that a successful company requires a team effort and we need to forget the Us vs Them mentality. In addition not recognizing the effort and contribution of the development team may cause friction whenever you need their help/support in the future.