Blog

Wednesday October 7, 2020

How developers deal with delayed feedback loops - A Manager's Perspective

Managers who are embarking on new business processes, brain storming, and who see software development as a means to an end (rather than a product) are prone to context switching. This is true for managers who are Innovators or Early Adopters and are inquisitive to see if a new development can solve issues that are emerging, anticipated, or as a way to gain a competitive advantage or industry leadership position.

Projects that have long meeting cycles (ie. monthly) lend themselves to informal discussions and conversations for the aforementioned type of managers and leaders. They are curious about what functionality may be available; can the development do this or that; can work flows be improved; and can secondary or other business objectives (which were not important because of prior effort) be addressed as part of the new work.

For these managers, those quick informal meetings or hallway or cooler discussions are insightful and provide assurance of progress and solutions. Conversely, reducing the number of meetings and eliminating informal contacts will frustrate these managers.

As a way of attempting to reduce efficiency but still provide client service, having a lead contact rather than multiple developers that a manager may talk to, can reduce the confusion or loss of efficiency. It allows the development team to focus on the work while the project team lead focuses on managing the budget, project scope and schedule, and the project charter.

More importantly, another strategy may be to set up frequent quick “touch base” meetings to assure the client about progress, the schedule, and budget.

Another strategy for projects, such as key strategic projects, is to establish projects as phases or components of a longer-term goal or project so that the business client has assurance that ideas and desired improvements will not be lost.

Sunday October 4, 2020

How developers deal with delayed feedback loops - An Intro

Oftentimes development teams, especially ones in fast-paced environments, find non-essential meetings and general product-based context switching to be an area that delays their development and release process. Context switching for developers can be as simple as someone walking past their desk asking a trivial question, or as complicated as managing multiple stages of their build and testing in different applications or UIs. As a developer myself, I often ask myself how best to manage both efficiency and getting the feedback I need with the right tools for the job. Sometimes it does require 6 different apps/sites/systems but often there are ways which can reduce this, thereby reducing the cognitive load and loss of efficiency when working. Can this be done by finding platforms that support multiple parts of the ecosystem? Maybe. Can it be through hiring more developers which allows for further defined tasks? Again, maybe. Given the climate we are in, sometimes those options are not possible. So what are the alternatives? Over the coming weeks we will review some such options giving unbiased feedback and musings along the way.