← back to the blog

Software Development: As much business as IT.

Posted on August 5th, 2017 in management by Simon

Having worked in a number of organisations during the last decade, I've begun recognising patterns between what makes one successful and another not so much.

One such pattern I've observed in companies that are struggling to deliver effectively is where Software Development specifically is treated as part of IT and not part of the business. In these environments, developers, architects, testers and managers are making solution decisions as part of IT, not in conjunction with the people accountable for the part of the business they are meant to be supporting.

These decisions are often based on solid principles such as maintainability and technical fit, but time and time again are not aligned to the targets in the business owner's mind.

As a person responsible for a part of an organisation, it is not acceptable to treat software development as an external party. If you are not involved in the solution decision making process you are not doing your job. If your development team has not discussed which of several implementation options is the most appropriate to meet the business goals, they are also not doing their job.

Software development is not distinct from the business, but is integral to it and part of it. In a world where we are increasingly reliant on automation and digital communication, if you are abdicating your responsibility for change to your IT department then you are not running your business, they are.

Similarly, if you have an IT management that is keeping you at arms length and saying "trust us to deliver on your behalf" then they are not supporting you to meet your responsibilities, they are undercutting you because they believe they know better.

The successful organisations I have worked for understand that there is no distinction between the business and software development teams. Both competencies work hand-in-hand to deliver capabilities that support the business goals whilst being appropriate from a technical standpoint.

Change is everyone's responsibility.

However to achieve this, business peope need to have an appreciation of the technology that underpins their business and technical people need to have an appreciation of the business.

Some items to consider for each type of person would include:

  • What are the different implementation options before us? What are the trade-offs between them?

  • How can we phase implementation to deliver value soonest?

  • What are the pressures on our technical people? How can I help with these?

  • How do I make sure the technical people feel like they are part of my team, not our suppliers?
  • Who are our biggest customers / customer segments? What are their needs?

  • What are our immediate business goals? What are our strategic goals?

  • What are the pressures on the business owner & their team? How can I help with these?

  • What is the value to be derived from what we are implementing?

Obviously these points are not exhaustive but give a flavour that both groups need to move toward each other to form a successful partnership. This doesn't mean that both parties have to be experts in each others' fields, but should have an understanding of them.

What is the point of having internal development resources if you treat them like an outsourced development team? You inherit all of the issues of an outsourced arrangement with the added issues of not having a robust software development team.

Similarly why not work for an IT outsourcing company if you do not want to be part of the business you are working for? You will inherit solid development processes and controls which are refined between multiple clients and many projects as opposed to the organically grown and often cobbled together software development processes you find inside other organisations.