There is a difference between Information Technology (IT) and established industries in terms of maturity in operations. Producing IT outputs is still treated as a knowledge-intensive activity, while in other industries the production is labor-intensive. IT is slowly moving from knowledge-intensive to labor-intensive, and innovations such as software factory model are trying to replicate the best practices of labor-intensive operations in IT projects and operations. However, not all areas in IT are ready to adapt the best practices of labor-intensive industries. One such area is project management.

There is a general perception among software engineers, at least among the people I know, that project managers are usually disconnected from technology. This perception then implies a casual disrespect towards the project managers who are supposed to lead the project team. A common trend is to have a technical lead to lead the team in techncial affairs and the project manager “restricts” himself or herself to balancing the project variables and ensuring the process compliance. In a knowledge-intensive industry that’s a dangerous practice.

There is a difference between leading a team where individual talent is more important than training. Research and arts are two examples where talent is more important than training. Modern manufacturing and military are two examples where training is important. A good manager, in my opinion, should be able to balance himself or herself between the extremes. He or she is then like a conductor, a coach and a commander, under different situations.

A conductor knows his work – the music – thoroughly. He may not have written it, but knows every detail of it. He can sense the composition, it’s expression, nuances, consistency and occasional mistakes. The musicians in an orchestra are individually talented and trained, and the conductor guides them to produce something that cannot be individually attained.

A coach knows his team. He is able to relate individually with the members of the team and build them into the roles that they must perform. He knows the skills, form and temperament of his players and is able to place them on or off the field.

A commander knows his enemy; a corporate “commander” knows his customer. In a sense the enemy is a customer for the commander – he delivers them missiles and bullets!. He is able to strategize the operation and instructs his officers to carry out the mission. Once they are in a mission, they are bound to it.

These leaders command respect through their knowledge, interactions and strategies. When team members are somewhere between researchers and laborers, artists and soldiers it is important for the leaders – or managers – to have a little bits of conductors, coaches and commanders in them.

Years ago, I architected a house. Being a Civil Engineer by qualification architecture is something that I was always fascinated with. Today I architect software, at least that’s what they say I do.

Architecture is one of the most misused terms in today’s software industry. There is an architect for everything – one for user interface, one for data, one for solution and one for the entire system. Then there are numerous technical architects who do all kinds of job – from design to coding. Then there are those obscure ones – lead architect, consultant architect, principal architect and so on.

In 1987 John Zachman complained that the words “information systems architecture” were losing the meaning. He then looks at classical architecture and draws an analogy in his famous paper A Framework for Information Systems Architecture. Through the introduction he describes the term architecture as some logical construct, and some kind of structure. Probably, that’s what we really want through the process or architecture – a logical construct, a structure to the system. Zachman then goes on to explain how architect lays out the drawings in different perspectives. And that’s it – that’s what an architect does.

An architect is someone who sees things and concepts in its final state – buildings, bridges, automobiles, hardware, software, process, enterprise and so on. He is able to visualize the solution and translate that into drawings; drawings from different perspectives. In classical architecture those drawings are usually elevations, plans, and sections. Three perspectives, those define the building completely. Then there can be details of all these. Everything else is design – structural design, interior design, landscape design and so on.

Architect defines the construct of the concept in an integral manner. Designers adapt different perspectives of it and design. Builders use the design to build different pieces. And it all comes together to something that the architect envisioned, before it even existed.

“Most people,” Roark says, “build as they live — as a matter of routine and senseless accident. But a few understand that building is a great symbol. We live in our minds, and existence is the attempt to bring that life into physical reality, to state it in gesture and form.”