I had one of those Twitter outburst last year that I realized mirrored a frustration I have seen manifest in every job I have had. In the interest of posterity I thought I would repeat those tweets here:
“The problem with my extended technical team is that it has very little control of priorities.”
In whatever business you find yourself the work of the Software developer is generally the most objective and measureable, this permits people with very little hands on software experience to treat the software process like a predictable black box, where some given input (requirements, specs, etc.) provides some expected output (a new application or feature).
When this process is working well the inputs make sense to the development team, the team executes the work, the output is sent back to specification and everyone is happy. The problem with the notion of a black box happens when the execution portion runs in an ahistorical and counterintuitive fashion. To folks providing the inputs nothing changes but to the people inside the black box this type of “anomaly” is expected and anticipated (because for them it is not a black box), and is not beyond a measure of control (by adding time).
Time then becomes the thing all groups attempt to bargain with, using it as a measure of the tasks complexity or simplicity (this may not be true), but it becomes the metric that all involved parties understand. Often missing from developer analysis are the upstream revenue concerns driving decisions. Your paying customer has partnered with you because there is some process that they need that they do not want to be responsible for managing, so if you only understand the technical concern your are missing almost the entire point.
The development team needs to bear the responsibility of ensuring that the black box does not become a black hole, in that no information (light) ever escapes. Part of the responsibility of your team to is take on the challenge of communicating what it is you do, so that you are fully transparent. Some of that is simply showing how bad design negatively impacts revenue. If you consistently fail to make this case it is likely symptomatic of an insular, homogenous team that needs to have much more one-on-one conversations with other disciplines (business, sales, etc.).
If you are in fire fighting mode, all the above goes out the window, you are out there to save lives at almost any cost. However, there should be a clearly defined moment or time where we are no longer putting out fires but are looking at the best way to fix and rebuild the house. Risky decisions you take when trying to save a sinking business should be completely reconsidered when you are firmly out of danger.
Solution space
Trying to solve a problem without a thorough examination of the underlying assumptions (inside and outside the black box) leads to recursive behavior, each iteration will only lead to an examination of itself, it becomes a nonsensical and resented exercise. Your developers should be able to make assertions based on thorough understanding of the critical upstream decisions even if that is a simple application of the Pareto principle (80/20 rule).
To someone who views software development as a black box I would avoid giving them bad design/process as Option B, just sharing positive design patterns as an option can also back fire horribly. In fact every choice you present to stakeholders outside of your dev team should be tied to an unambiguous and unimpeachable business case.
Comments are closed.