Organizational Structure
The people designing and developing a software solution are determined by the organizational structure. The structure determines if the software solution has a consistent set of people working on it or if subject matter experts (SMEs) and technical specialists are brought in for much of the work. For the sake of the software solution, retaining the people that originally developed it throughout the lifetime of the solution is usually optimal. Organizations using software created by external consultants can usually expect few developers to stay with the product for a long time. From the perspective of companies developing software for others, the solution is often delivered under a limited engagement and other developers fix bugs and make future enhancements. Matrix organizations, in which an employee, particularly a software developer reports to a manager regarding their performance and skills, but reports to a product or project manager regarding the work they are doing, can lead to ambiguity and conflict in prioritization of the employee’s expected duties and where they should allocate their time. Teams composed of people in significantly different time zones face challenges not experienced by teams located together. Small companies focused on developing a single product (startups) incur minimal impact from organizational structure as they have very little.
Examples of organizational structures:
- A small company with one team of developers that produces a software product for external customers.
- A large company with hundreds of developers writing software for many external and internal applications. Team members work on different products as they join different project teams for three months to a year.
- A consulting company that writes software for a client, then moves on to a new client.
- A mid-sized company with many developers that are specialists and specialists join teams temporarily as needed to work on projects. Developers report to both project managers and department managers.
- A small company with a few developers, each of which is solely responsible for the software solution they support for internal or external clients.
- A company with developers spread out around the world working on the same product.
- (Startup) A small team developing a product for resale.
Considerations
- Consultants that will walk away from the product will focus less on investing in the long-term quality and stability of a product, especially if there is contention between the consulting company and product company.
- Developers dedicated to a single product/solution often feel more ownership and focus more on what is best in the long term and expend extra effort to improve quality. Conversely, developers that know less about the product overall are less able to make the best decisions about quality and functioning for the long term of the product.
- People don’t know what they don’t know. People that have only worked on one product/platform for years or decades may be unable to imagine the significant improvements that could be made adopting techniques and designs used by other solutions.
- Distributed teams and remote teams may need more structured and forced interactions with their team members to build community and trust with each other. People tend to put out more effort when they feel they are part of a team of like-minded individuals.
- Example: Regular, online ceremonies demonstrating features delivered may be more valuable to increase communication, feedback, and build community.
- The more teams you have (that need to interact) the more you need to establish some commonality of tools, dev processes, and deployment processes.