Microservices and Containers (e.g.Docker) bring another revolution to the software industry, machines faithfully following Amdahl's Law. Man on the other hand is not as fast to change as the machines one invents and is still faithfully following Conway's Law. How can this struggle be managed ?

Technical Coaching is the answer

"The fundamental learning situation is one in which a person learns by helping someone who really knows what he is doing." Christopher Alexander et al., A Pattern Language, p. 413.

Technical Coaching is a specialization of the Coaching discipline applied to the specific context of the technology filled environment we live and work in nowadays and the specific challenges of both the executive and middle managers as well as tech leads and software engineers that deliver this technology into our lives.

But first, let's drill down a bit into the contexts of these 'opposing' sides we are referring to.

Machine Context

Microservices and Containers (Docker, Rocket, Solaris Zones, BSD Jails) are the new shiny things revolutionizing the software industry nowadays. They are pushing everyone to reconsider their software's architecture and development models as well as the technologies we use.

They also promise to significantly impact the efficiency of teams, allowing for easy separation into smaller collectives that can easily respect the two pizza rule and also to significantly reduce the induction time for new members of the teams, even when they are not very experienced (juniors), because of the simplicity of each individual service. Of course, it also reinforces the crucial role of the software architect as a must have for any product or solution.

This is all nice and exciting for applications written in the Microservice style, but the issue, as always, is what do we do with the legacy monolithic applications we already have and depend upon as a business ? Can we apply Microservices to such beasts ? Can we containerize them ? Should we ? And most importantly, is it worth the investment ?

Man Context

In 1967 Melvin Conway postulated the following:

"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure."

Melvin Conway

The law is based on the reasoning that in order for a software module to function, multiple authors must communicate frequently with each other. Therefore, the software interface structure of a system will reflect the social boundaries of the organization(s) that produced it, across which communication is more difficult. Conway's law was intended as a valid sociological observation, although sometimes it's taken in a humorous context. (source)

The Challenge

In my experience as a software developer, project manager, software architect, trainer, technical coach and consultant I have learnt that changing and learning technologies is very easy. Chaning the communication structure of a team, organization and ecosystem of organizations, therein lies the real challenge. I've seen companies trying to adopt Agile Methodologies, Cloud Technologies, Microservices, and many others, and I can tell you every single time the success of all such initiatives resides solely with the management team's capability of Managing Change in People.

Change in people, many or few, always starts from one person. That person is not always the most influential, nor the best positioned in the oganization to be able to push the change forward onto the rest of the group. Finding, nurturing, motivating, encouraging and empowering such behaviors is the best way you can ensure your company's agility to the point where you can catch up with the change in technology and lead tomorrow's market.

Technical Coaching is a very efficient and effective way of starting the change cycle in your team or organization. It can help build up the critical mass of people who will take your companny on an incredible ride beyond any competitor's grasp.

More on this in the next article. Keep close.

---

Author:

---