Development Topics
| Product Management | Agile (SCRUM) Development |
| Quality Assurance | Architecture |
| Leadership Team | Integrity |
Product Management
The relationship between Development and Product Management is crucial to success. Although there is often an argument that Development should own the product management role, it remains one of the crucial inter-working relationships that define the level of successful achieved in a technology company. Product managers who come from Development tend to succeed more in this crucial role as they have the respect and the inner-workings understood of the team. It's harder, but not impossible, to successfully fill this role with outsiders and certainly possible to fill it with a pre-sales support specialist (SE) who can also be excellent.
The product manager provides Development with the blue print for what each release needs to contain. Development takes that hand-off and internalizes it into plans and objectives for the teams. The product manager works hand-in-hand with the various team leaders to track projects through their cycle and to assist in making key decisions throughout. Ideally, the product manager is the final authority on any project deviations, but in reality, all stakeholders should be involved in making "deviant" decisions.
In this section, we'll dig into more detail to better understand the respective hand-off points between Product Management and Development as well as the typical events that occur along the way of a release cycle. If you view this as a middle-management activity, it may be one of a few the CEO should pay attention to if success is a goal. 
Agile (SCRUM) Development
There are a variety of approaches used to produce quality software products, arguably most are not implemented well as evidenced by the plethora of poor quality products in the market. Some form of Agile development seems to be in vogue in many shops, largely designed to address two key industry weaknesses; improvement of quality and responsiveness to changing requirements. Formalized Agile processes can also help when you would otherwise have very large teams working on a complex product output.
The Agile technique tend to turn on end the traditional model of product development, but can work best when holistically committed to by an organization. It affects the way Product Management, Marketing, Support and Services work with Product Development, so it can be a bit of an undertaking if you are converting from a traditional model.
Let's explore the pros, cons and alternatives to Agile development.
Quality Assurance
How is quality software produced? Who is responsible (accountable) for quality? What is an acceptable level of quality? How much should I invest in quality? There are many jokes about quality in the software industry (or lack thereof) -- imagine a world where your car would only take you to about 7 of every 10 destinations you needed to go to. Poor quality is hard to recover from, customers lose confidence, competitors gain an edge. Great quality is hard to obtain, but does bring with it many leadership benefits, including customer/market loyalty.
Attributes of an organization that delivers quality often include many of the following - definable architecture, patient product development team, well-managed development processes, team coherence across disciplines, clear market requirements and more. Of course it also helps to have great developers but even poor developers can deliver acceptable quality if everything around them drives them towards it.
Let's examine how quality is measured, achieved and sustained throughout a product life cycle, many variables but all manageable in one of the more visible aspects of a quest for excellence. 
Architecture
Google defines Architecture as "the structure and organization of a computer's hardware or system software". It also defines it as "a fictional character appearing in the last two films of the Matrix trilogy". The latter tends to be more how the role of Architect fits into most growing organizations. An important role for sure, key to building a sustainable platform that can support a long lasting product life cycle. Products that tend to struggle from version to version often are built without sound architectural principals, something not easy to govern from a leadership team perspective. It is also near impossible to afford changing the fundamentals of an architecture, so care has to be taken to establish it with sufficient forethought at the start.
The most common fix for poor architecture is to appoint someone as the "Architect". Big shoes to fill, often heading towards contention and controversy, especially with other senior development team members. In physical constructions, such as buildings, the Architect is key, creating the plan used in making something. Unlike physical constructions, decisions to change things occurs every day, so it is often difficult if not impossible to keep adapting the architecture to fit the realities of how software is built. If we learn from other specialties, we would find that the architect often has to sign off at key stages of a construction project -- wielding big power as a result. It's not clear that this kind of implementation would work in the world of software design. One could argue though, once the architecture is set, it should not be allowed to change. But alas, software development is not such an exact science governed by physics and other non-bending laws of construction that certain implementation changes would not work.
We'll look at what's important about architecture in the overall Product Development process and what responsibilities, if any, should be assigned to any one individual (or group) who embodies the architecture itself. It is true, if you do not have a defined architecture, you are likely hunting in the dark for product excellence.
Leadership Team
Development leadership often excels around the development process, making sure the outcome (e.g. product) addresses company needs. Contributions to the Leadership team itself can sometimes go by the wayside. In many situations this is acceptable as the balance of the leadership team focuses on sales and marketing, an area strong Development leaders do not often have specific insight (this is not an insult).
In fact, this can help avoid the inevitable "what do you know about it" tension that can exist between Development and the Sales/Marketing leaders. Nonetheless, the role of the CEO includes developing the strengths and weaknesses of the leadership team so you do need all members to strengthen the whole. Let's examine ways in which Product Development leaders can make strong contributions to the leadership team instead of just sticking to their knitting.
Integrity
Integrity of the Development leader should go without question, but what about the team as a whole? Serious areas to keep a spot light on include commitment to quality (versus shortcuts to meet deadlines), illegal use of unlicensed code (including from Open Source projects), acceptance of responsibility to meet product requirements, desire to learn new techniques, take input from outside of Development and more.
Many of these issues arise through normal course of operations, not deliberate, but a by-product of the way Development is managed. Areas to examine further include use of meaningful performance metrics, reward/recognition systems for key achievements, relationships with other areas of the operation (especially product management, QA and support). Integrity does tend to be led from the top, so the CEO needs to instill culturally a desire from Development to be part of the team, equal among many. Let's examine this further.
Hiring and Interviewing
Choosing team members for development is a challenging process. You can spend all your time trying to qualify technical skills and select someone who does not fit into the organization at all. You can choose someone with an excellent interpersonal fit, but ends up falling short on the technical side. Choosing developers is a key resourcing activity but may be something that the CEO is not able to help much with without having a technical background. We'll focus on how to explore the suitability of a developer and what hiring process might work best for you organization.