During my years as a manager here at Patriot Software, I’ve noticed that some college grads and first year devs enter our company expecting to be told exactly what to do, how to do it, and what success will look like. While I appreciate their desire to work hard and achieve success, the truth is, if our objectives were always clear-cut, I wouldn’t have needed to hire a software development team to help me figure them out!
Software development is a creative art. And being the manager of a software development team is a delicate balance of finding proven skills borne in structured environments, then teaching the people who own those skills to let go of their structure and thrive in finding creative solutions to abstract problems.
Meeting Requirements vs. Creative Problem Solving
To help find the skills and personalities needed to tackle abstract development problems, I often ask interview questions relating to how a dev candidate deals with changing requirements. It’s my belief that, while many young devs learn how to use code best practices in college and training programs, they don’t always learn or get rewarded for finding creative and unique solutions. This can lead to a desire to meet requirements instead of developing a passion for your work and creative problem solving.
Now, that’s not me projecting experiences on young devs coming out of college. I’m in an MBA program right now, dealing with structured expectations on a set track. In college, you get a syllabus and you’re asked to deliver fully flushed out items on a schedule. When you do it, you get a good grade. When you don’t, you get a bad one. But in the real world, there is no syllabus, and no professor telling you what the correct solution is and whether you got it right or wrong, and why.
Ask The Right Questions to Find the Right People
At Patriot Software, we find that, when conducting interviews, it works much better for us to ask people what they are doing on their own time. What are they reading or building; or trying to solve just for fun or because they are curious? How are they doing with it? What do they want to know, and how are they finding information? These questions tell us about the more important software engineer personality traits, like how inquisitive and original they are— and you can’t discount that.
If you’re going to solve any major development problems successfully, you have to be able to break down projects into smaller sets of deliverables. However, I learned very early on that, if I break down a project without giving my software development team a chance to see the entire problem, I create more work for myself and offer less incentive to the development team. In some cases, I was denying them a chance to solve the entire problem with an innovative and original thought.
Here is how it used to go: I’d break the problem down into pieces based on how I thought it should be solved. I’d then show one small piece to a member of my development team and tell them how I wanted them to complete it. They’d start working and, when issues came up, they would come to me with question after question after question because they assumed I had all the answers and knew exactly how the problem was to be solved. Not true! Moreover, in trying to make it simpler for my devs, I’d actually created more work for myself because I’d denied them the chance to find original solutions.
Unleashing Your Software Development Team
When you give a developer just a little piece of a solution, you might feel like you’re doing them a favor. However, if they don’t understand the whole problem, they won’t make a solution for it, or, the solution they make may not fit into the whole. Worse, handing out little pieces and obscuring their vision of the entire process means they’ll come to you over and over again, and you just don’t have enough time to get into the weeds with all of the issues. Your software’s speed-to-market will suffer in the process.
I’ve found that it’s best to unleash your development team by letting your devs see the whole picture as they work to come up with solutions to their part of problem. Show them what the issue is, and what you’d like them to work on, then challenge them to make the best solution they can. Unleash your developers’ creativity and let them test the waters of a structure-free unknown. Often they’ll come up with their own creative solution that is better than what you’d have come up with!
When you empower your devs to brave the unknown and break free of small box approaches, they invest more ownership into the project, are more engaged with their solutions, and provide more value to the team—and the company—as a whole.