Good Software Owner/Bad Software Owner
Photo by Stephen Dawson on Unsplash
In a mid to large sized company, there are often owners for different parts of the software. The quality of the work these owners do can make all the difference in delivering high-quality software that meets the needs of users and aligns with business objectives. We'll explore the contrasting characteristics of good and bad software owners, highlighting the essential behaviors and practices that set them apart
Good Software Owners deeply understand the users of their software, internal and external. They understand context around it, its ecosystem, the product it belongs to and the platform its built on. They understand not only where it is now but also where it needs to go to support the strategy of the business. They make good and timely decisions based on this context generating tangible business value. Bad Software Owners make decisions without their users in mind. They justify them in either exclusively technical terms or make project and technical decisions that end up being bad for their users. They resign to how the software is today and make excuses to why they can't evolve it.
Good Software Owners understand they're also leaders. They take proactive action to make sure their software functions and evolves properly. They communicate and collaborate broadly, identifying risks and opportunities and getting ahead of them. They make sure that they've set up ways to acquire information to make effective decisions in their software. Bad software owners have a lot of excuses as to why something came up that delayed the project or that caused quality to either stay or become bad.
Good Software Owners share knowledge and responsibilities with their team to avoid being a single point of failure. They create an environment of transparency and trust, provide the team with the necessary tools and resources to work independently, and encourage ownership of the software. In contrast, Bad Software Owners hoard knowledge and responsibilities, creating a culture of dependency on them. They micromanage the team, don't work on making information and resources known, and do not encourage ownership or transparency.
Good Software Owners shape their organization's processes and ways of working to enable high quality and speed of innovation through continues improvement. They're always looking for ways to go from future insight to working software faster. They make good investment decisions on which issues to prioritize. Their teams are frequently working on making their own operational context lighter and better. By fixing issues at the root cause, Good Software Owners prevent the same issues from recurring, which improves the software's quality and reduces the cost of maintaining it.
Good Software Owners frequently track and derive insights from measures both business and technical. They don't wait on a problem to happen, they work on important issues before they become urgent. But when an incident does happen they're quick to fix the issue and also implement an action plan that ensures sustainable quality. Bad Software Owners act and speak like incidents and issues are "happening to them," like they don't have agency. They don't know what measures they should track and don't look at what is already tracked. They are slow to solve incidents.
Good Software Owners collaborate with teams that report risks, bugs, or architectural improvements, treating them as partners in creating better software. They work together directly, providing insights for similar software improvements, and welcome feedback on their software. They provide clear deadlines, plans, and collaborate on solutions. In contrast, by seeing other teams that do this as nuisances and providing excessively long deadlines, Bad Software Owners create a culture of mistrust and delay that results in slower delivery and lower-quality software.
Good Software Owners acts on supporting teams that need to interact with their software. They review code being added to their software thoroughly and swiftly. They see the code reviews as opportunities to understand what's hard to change in their code. They understand that if changing the code is causing bugs this often means that their code design is not good and act on improving what's hard to change. They answer thoughfully and quickly to information requests or help that other teams need. They look to those as opportunities to improve how well written, thorough and acessible their documentation is.
And last, because of all this Good Software Owners are examples to how we make software. They're constantly providing best practices and platform improvements to the company because they do their research and are not bound to "how things are done now." They act and are seen as leaders. Bad Software Owners are always complaining about the platform limitations and on "Product/Deadlines/This/That not allowing me do to my job" but don't act on solving these issues.