Simon Brown talks to us about how, now days, we have many diagramming tools and concepts which some of us like to use, and sometimes are even imposed upon the developers by the corporations managers, who actually have no idea of technicalities and the usefulness or not of those diagrams. However, despite the tools and concepts we have, when we create a diagram of the architecture of a software program we are developing, most of the time it ends up not matching the actual code, we can not see the architecture in the code.
Years ago, after finishing my bachelor in computer science, while doing my specialization studies in teaching and, later on, while doing my masters in leadership and management, I had several subjects about psychology, management and leadership. Although I never excelled in human sciences, I always felt great interest in them and was a successful student at those subjects. The explicit concepts learned back then have since been fading away, leaving me with scattered implicit concepts, knowledge that I don’t really know where it came from any more, nor even if it has any validity.
Thus, I decided to refresh and update my knowledge, so I searched for some conference talks and articles about the subject, and decided to leave here my notes about what I’ve learned and re-learned, as well as a few opinions derived from my past team leading experiences.
Building and leading teams into performance is not an easy task, there are just way too many variables to be predictable. It’s after all, a human science. Nevertheless, there are many studies, theories, behaviour models, guidelines, questions and answers that can help us build and lead a team into performance.
“The reasonable expectations of your new CEO”
There is software everywhere! And it must be work! It must not fail! People depend on it!