The definition of “big 5” is traditionally
the 5 most dangerous african animals to hunt on foot. For software development I have defined it as
the 5 greatest dangers of running your software company.
A lot of legacy code and not aggressively reducing technical debt is a sure way to keep your IT organization on a low level of productivity and high level of frustration. With technical debt I mean for example spaghetti code and poor architecture, lack of or bad APIs, lack of tests, no modularization and no continuous refactoring.
If you are building a new system letting the above happen is a good way of making sure you will have potentially fatal problems later. An example is not refactoring the quick prototype you hacked together for your first demo or letting your test and deploy infrastructure become a mess.
Weak technical leadership
Relying on cowboy developers, whole development teams or disconnected managers to lead in important technology and architectural decisions will likely result in fragmented architecture and endless discussions. Worst case examples can be taken from public examples in Sweden where bad technical decisions wasted tens of million euros of tax payers money.
Even if bad decisions does not topple your business you will likely end up with sub-standard development tools and practices and lack of Continuous Delivery, DevOps and Lean Startup thinking. This will in turn reduce your company agility and the best tech people find a cooler place to work.
Waterfall project model
Although Agile development has become a de facto standard for software development many companies still employ traditional project management and a waterfall-ish project model in the rest of the organization. It is not that these methods are bad per se but in a fast-moving hyper-complex environment they are simply no longer up for the task.
Over-emphasizing control, long term detailed plans and disconnected phases and departments will reduce corporate agility regardless of how agile the IT department is. Traditional project management also tend to create short term thinking, lack of time for improvement work, poor collaboration between projects and lack of an overall perspective.
A common method of slowly killing your business is by pushing product decisions through the organization without capacity control or quick feedback loops from the people implementing the functionality. This will create a cadre of cynical and unmotivated developers that will argue they “won’t have time” for testing, refactoring, improvements and other practices that are part of being a professional software developer today.
Even less time will be spent on knowledge development and knowledge sharing, making you dependent on single experts to run your IT organization. Time for innovation..? forget it.
With good intentions managers let teams self-organize. With self organization comes higher demands for boundary setting, visionary leadership and skills in creating an environment where teams thrive. Many managers lack this capacity and instead disconnect themselves from the place where the work gets done. By doing this they lose the feedback mechanism necessary to properly support self-organization and effectively hand over the development organization to whatever winds are blowing at the moment.
Note: As an organizational systems developer I tend to see things from a people perspective. Starting with looking at technology is equally valid. If you map the dangers for your organization in a so called systems dynamics diagram you will probably see that they are reinforcing each other and that they are mutually inclusive.
Latest posts by Emil Vikström (see all)
- “Big 5” dangers for your software company - March 10, 2015
- How to produce successful change - November 19, 2014
- Guest blog: Stepping Stones into the Future through Leadership Agility at Ericsson - September 1, 2014