Tech Blog Launched!

Here is a new one: I have started a tech blog on GitHub: http://alexandrugris.github.io/ :). I will also keep updating this one, as the two blogs have two very different intents behind.

The management blog (www.alexandrugris.ro) is mostly about interesting insights I have from time to time, mostly on topics like management and leadership. I write when I think I have something (hopefully) original to say or, as it happened before, when I stumble upon an interesting managerial challenge which drives me to analyze the situation deeper, to extract a pattern. If I find my conclusions to be interesting enough and applicable to other situations, I put it online.

The technical blog on the other hand will probably be driven by my own play with various technologies. I start it with the idea of having a log where I jot down the stuff I experiment with. I don't expect it to have a unifying theme although, as it seems right now, it might evolve somehow towards distributed systems, software architecture, coding techniques and parallel computing. But that is just because these topics are on my reading list these days.

Agile With Structure

Last year I passed the AgilePM certification (DSDM methodology). The main benefit this methodology brings is, I think, rigor and structure to the Agile world. It bridges the world of software development with the world of large enterprises, bringing in an adjustable layer of governance on top of the team-oriented practices Agile is known for (Lean, Kanban, Scrum, XP). DSDM starts from the premise that everything is adjustable, but in order for things to go smoothly a certain level of up-front planning is needed, a certain level of organization, with more traditional roles and responsibilities, is needed in order for various projects within an corporation to become predictable. It paves the way for better Portfolio Management and synchronization at the project level, not only at team level. 

Here are some slides I put together regarding the methodology. Most of the pictures come from the dsdm.org website, the home of the methodology. Links from the slides are put as caption under each slide.

https://www.dsdm.org/resources/dsdm-handbooks/dsdm-atern-handbook-2008

https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/

https://www.dsdm.org/resources/white-papers/the-dsdm-agile-project-framework-for-scrum

Moving from Autonomous to Collaborative - A Must

Not a new idea, I think I met it first in The 7 Habits of Highly Effective People, yet I recognize it more and more as time passes by.

In the model above, collaboration is depicted as the next step from autonomy. Given the huge amount of studies showing the benefit of autonomous, self-organizing teams, it is easy to get caught into the trap of viewing autonomy as a walled garden - which is precisely the opposite.

I think a collaborative attitude is a responsible attitude. It all starts with autonomy as a prerequisite: you are assigned an area of responsibility, you are accountable for the results (both upsides and downsides, skin in the game) so, in order to succeed, because you are self confident and responsible, you are not afraid to discuss your plans and strategies with others. In the end, the decision lies with you so you do your due diligence  and consider several points of view.

According to this evolutionary model, from dependency to autonomy to collaboration, I don't think one can be truly collaborative as long as one is not granted autonomy and responsibility. I think COLLABORATIVE = AUTONOMOUS + RESPONSIBLE(upsides, downsides) while ACTING RESPONSIBLE means not taking disconnected decisions but rather reaching the right decisions by being connected to the environment and incorporating several points of view. The beauty of this recursive definition is that it shows the reinforcing pattern of collaborative attitude - once this path is taken one can only value it more.

I think the problem is that people view one's ability to act autonomously as the ultimate goal. The fallacy lies in the fact that successes tend to appear sooner while negative consequences tend to appear much later, disconnected from the time of success reporting. For the individual it is dangerous as it makes himself / herself obsolete sooner or later, while for the organization is a disaster waiting to strike.

I believe being autonomous and stopping there is a result of not enough self confidence. As people succeed, they develop work patterns which they apply successfully reinforcing their beliefs while, at the same time, they build walls around themselves to protect their beliefs. It is painful to prove yourself wrong or inaccurate. It is confidence and ego-shattering. Yet this precise attitude leads to restricted learning in adults. It is OK for a while, an example of a local optimum where "good is the enemy of better" and of short-term comfort at the expense of long-term development. 

I don't think it is possible to effectively learn enough to be successful if one is to discover everything by himself / herself. There is simply too much out there. Networking, reaching out, asking what one may consider "dumb questions" is a must. Being vulnerable is a must. Opening up your work is a must.

I think it is great to have strong teams that return results quickly, without ties. It is fast, it is agile, it gets stuff done, but not at the expense of learning and sharing. The should be embedded in the fabric of the organization, in its KPIs, and not trade collaboration effort for short-term achievements. When 80% is not enough, you can only go higher through dialogue - and this is expensive and painful. I think we live in a non-linear world, which only becomes more non-linear as time passes by. That means more investment in risk management on one side and on beating the market on quality and innovation on the other side. Both are learning activities which involve collaboration between various experts, interdepartmental connections, between various companies, in some cases including even the competition. Autonomy understood as island, walled garden, ivory tower is simply a recipe for failing big:

 

The image above is quite self explanatory - as success is built on top of another success, more trust is gained, more money is involved. The problem with trust is that it grows linearly (or even exponentially) while the single failure is a one-time event that might have disastrous consequences (think turkey before Thanksgiving anecdote - so far so good). In such cases, collaboration and showing openness to dialogue and vulnerability is what strengthens the system, as through low-pain but frequent interactions it helps uncover cracks and assumptions which, otherwise, get undetected and produce major consequences sooner or later. 

In short, being autonomous is not enough.