Rules, Tools, Schools and Teams

Over my career I’ve been a technology evangelist.  I was passionate about Object-Oriented Programming (OOP) – if you didn’t develop in Smalltalk then clearly you didn’t understand the future.  Then I refined my thinking to Component-Based Software Engineering (CBSE), which I understood to be a more practical application of OOP.   Then years later I was a leader in adopting Business Process Automation in Accenture, including leading their alliance with Pegasystems, and in my last years there I was an advocate for the adoption of Cloud Computing.  A personal common thread for all of these technologies that I advocated for was a frustration at their slow adoption and the difficulty people had implementing them effectively.

Slowly I began to refine my point of view to understand that one truth about software is that almost any technology can be made to work well or fail spectacularly.  The variable is not the technology but the people who implement, support, operate and use the technology.   One very positive trend I’ve seen is the widespread adoption of a focus on User Experience.  The good news is that we are increasingly focused on building software that people can use, or at least trying to.  But I fear we haven’t made as much progress on the other side of the software – the people who build, support and operate the software.

An expression we used to use was that we had to focus on “rules, tools and schools” – which translates to making sure that our people had the right methodology, tools to use, and skills (training). One of the concepts was that focusing on these areas would help people raise their game and be more effective.  We believed that the best, most motivated people would be able to learn, develop processes and tools on their own but that the majority of the people could perform at a much higher level with some help in the form of “rules, tools and schools”.

I still believe that this concept was right, but was missing one element – teams.  In most cases software development, maintenance and support is a team effort.  As leaders and managers we should put as much attention into how our teams are formed, their cohesion and dynamics and how they are measured and rewarded as in the other areas.

I plan to share experiences and resources that a practitioner can use to focus on methods, tools, skills and teamwork which I will argue are the four keys to successful, effective software engineering. The reader and user of this information is intended to be an executive, leader or manager in a company that develops and supports software with a business focus.