Thursday, November 4, 2010

1 Making egoless decisions

1.1      Collaboration  


  1. Members of an interdisciplinary development team:
·         This could include graphic artists, content experts and specialists in various aspects of web site development, such as site navigation, database programming, business logic and user interface design.
·         Each member of such a team has their own set of interest, priorities and criteria for success.

  1. Middle managers
·         This can include technology specialists, such as a lead programmer and a system architect, as well as commercial leaders, such as the project and product managers.
·         Usually there is an inherent hierarchy involved here that depends primarily on who generates the most revenue for the company.

  1. Clients and investors:
·         There can also be several layers of clients, depending on what’s being developed. For example, in chapter 15 we talk about risk management for people who invest in the company through fund managers.
·         These investors can be viewed as owners, whiel the fund managers are “clients”, since they must be convinced to buy into the company and remain.
·         For simplicity we will usually we will refer to the “clients” as the ones paying for a given product or service and the “owners” to be the principle shareholders in the company, but where applicable we will be more specific.

  1. Senior managers, board members and owners:
·         Every company will have at least one senior manager (e.g. the CEO) and/or owner, but usually only public companies or NGOs have boards or directors. Sometimes there can be many of these and then the challenge becomes to avoid conflicts of interest.
·         For example, the senior managers may not agree with the board on priorities, since the latter represent the share holders and the former represent the staff. This is known as the “agency” problem.
·         Similarly, these days it is frowned upon if the CEO and chairman of the board are the same person, since in that case major decisions may be bulldozed through without due diligence.   

Thursday, September 16, 2010

15.4 Managing investor risk with Agile Development

My comments today are relevant to what an investor has to do to ensure their funds are optimized in the hands of a high tech entrepreneur. However, much of this discussion also applies to the valuation of companies..
Most technical people are so focused on their favourite technology that they have little time for or interest in marketing! This is probably one of the two biggest reasons that so many start ups fail in this sector. The other is that they often lose control of the burn rate for their venture capital, because their expertise is not in budgeting either.
So, that’s where people like me come in, Since I started out as just another programming geek, my initial involvement with business expertise came from on the job training as a middle manager. The experience gained progressively from roles such as team leader, project manager, system architect and director of development gradually taught me how to focus on the needs of clients and correlate that with corporate strategy.
A key factor here is the ability to absorb the relevant technical information and then translate it into terms that clients (and their customers in turn) can easily understand. Another very important factor in the success of software teams is to motivate the developers so that they feel engaged in the client’s objectives (i.e. how will they learn new skills and advance their own careers by addressing the client’s needs?).
In my case, by returning to school to do an MBA, I was able to significantly adjust my perspective on these issues. My exposure to risk management, finance, marketing and accounting principles taught me that high tech companies are often putting their efforts in the wrong place. In particular, their corporate strategy tends to focus on a shotgun approach to please everybody, rather than identifying and zeroing in on specific niche markets. Thus the companies that manage to do the latter tend to be more successful.
What does that mean in terms of Agile Development? The key here, which was really not emphasized much last night, is that the Agile methodology emphasizes an iterative approach to software development. In other words, the product is developed a little bit at a time, with constant feedback from the client, as opposed to delivering huge chunks at long intervals.
Thus the deliverables for major projects are produced every 2 to 4 weeks, instead of every 6 months.  This means that proofs of concept are tested out and prototypes are developed early, which diminishes the risk tremendously. The idea is to address all unknowns as early as possible in the product life cycle and adjust the plans accordingly, so that the project then can proceed without any major surprises. From a risk management perspective, this is a huge improvement over the previous paradigms, such as the infamous waterfall model, among others.