In the last two years the pace of digital transformation has accelerated for most of our clients. Many with existing technology platforms have questioned how they can keep up and if they have the right in-house support? Often, we run into many small businesses that are entirely dependent upon the skills (and motivation) of a single, isolated software developer. Not only is this risky from a business continuity perspective, but it can be exceedingly uncomfortable for a non-technical manager to question their sole developer when things fall behind or fail to meet expectations. Push too hard and you can easily alienate a critical team member, however taking the hands-off approach can be equally risky. As a “non-coder”, what is the best way to gain insight and approach your developer to understand both risks and potential opportunities?
Here are some key questions to get the conversation started:
#1 Do you have any current blockers preventing you from making progress?
Rather than put them on the defensive, ask the developer to be specific about what may be holding them back. In agile terminology, a blocker is just what it sounds like, “anything that stops or slows down the delivery of a product”. While a developer may not be able to educate you on the intricacies of the entire project, drilling down to a specific blocker can focus the conversation and position you as an ally.
#2 Is there anything we could remove from the scope to accomplish this task more quickly?
Quality developers are used to negotiating scope and understanding where they can make adjustments in their approach to accommodate timeline shifts or changes. In fact, a common complaint among developers is that business people always try to include too much in a sprint or release. By showing an understanding that trade-offs are possible, you may be able to enlist the creativity of your developer and even give them more agency in the process. On the other hand, it could be a potential red flag if your developer insists there is only one-way to accomplish the larger goal.
#3 Do you feel like the requirements are clear for this particular task/feature?
I often tell our development teams that clarity is a two-way street. In my experience, business people often think they are being clear and concise but developers need a level of specificity that most do not realize. Even a well-written ticket with clear acceptance criteria can be interpreted in several ways. By acknowledging this fact and opening the door for further discussion, you are taking responsibility for creating clarity and inviting the developer to express any gray areas that remain.
Digital solutions are among the most powerful levers we have to be innovative and push our business forward but they are not without risk. A business person that is unable to partner closely with technical experts, gain their trust, and acknowledge their power puts their business in potential jeopardy. At FortyAU, we love problem solving and collaborating to offer our own unique blend of pragmatic solutions.