info@fastwhitecat.com

Blog Fast White Cat

WHAT HAPPENS BETWEEN X AND Y, I.E., MANAGEMENT IN IT

Karolina Obszynska Sep 01. 2022
Effective performance in the world of business is a constant attempt to grasp many big and subtle factors in order to execute set goals. It is somewhat like a game of chess, in a situation when we are playing against many players, one both sides, not knowing the placement of some pieces (the pieces often changing their position without us knowing). Furthermore, we do not even know which pieces are at our disposal or what the board looks like. In other words – we are trying to play by the rules, rules which we think we know.


In these conditions, when we know that we don’t know all we need to know, we search for such methods which will allow the organization we are responsible for to  be effective in every respect – both the execution of business objectives, and the “soft” objectives, which are often less obvious. In this perspective, management could be treated as both science and art. I personally think that both aspects are key and underestimating either will result in inadequate management. By science I understand, on one hand, the use of appropriate methods of management, and on the other, measuring and using key business metrics. In the aspect of art, I see creativity, intuition, empathy, and a “fresh outlook” on daily organization.

The goal is to set the objectives


If I had to use one word which would best characterize my view of management, I would use the word pragmatism. If something does not work then it has to be improved, even if the textbooks say that it should work. If something works, we use it, even if the textbooks do not mention it. Always, consistently, it is worth asking the question - “what is the objective and how can I execute it better?”
If we are talking about project management, it is always worth referring to the contract. It is the often underestimated document which effectively defines what we agreed upon with the client. That is why it is critical to understand the needs of the client at the earliest stage of the discussions and definitely writing these findings up. Even if, in a sense, it is a process which is destined to fail – it is impossible to agree on everything upfront, there will always be greater or smaller misunderstandings. In our Polish reality, few people decide on agile contracts, where we can relatively freely define the scope of works on the go. At our disposal we usually have classic fixed price contracts which we attempt to execute in an agile model, which does not always turn out well. Hence, well defined and written up project objectives are half of the success.
If we are talking about company management, we remember that we are managing the business in the name of the business owners. In this case, it is the business owners with whom we need to agree on whether, e.g., we are aspiring toward a fast income increase or whether we prefer to invest means in ideas which will bring more benefits, but in a longer perspective.

“It is not about doing everything the right way. It is mainly about doing the right things.” (Peter Drucker)

I am guided by the question about objectives not only when discussing key strategic aspects. If you are in a situation similar to mine, I assume that the number of tasks you have backlogged exceeds not only an eight-hour workday, but sometimes even … 24 hours. Basically, processing everything that lands on my desk is unfeasible. Of course, we could talk about delegating tasks, etc., etc., but that is not the subject of this article. The right question should greatly facilitate the choice of things I have to get done today, assuming that not everything can get done. “So, what is most important today? From the perspective of my company’s objectives, what should I deal with right now?”

 

Attitude toward management

A classic attitude toward management, which seemingly should be long gone, still functions. Returning to the chess analogy, we have a player who is greatly convinced about their level of knowledge and infallibility, trying to set the pieces up according to the “divide and conquer” rule. When this behavior does not bring the expected results, they start yelling. the louder they yell, the more their methods do not work, which in turn causes a loopback effect. If this person has a smidgen of self-reflection, they eventually realize that something has to be changed in their behavior because it is difficult to expect better effects without a change of attitude.

Where does this attitude come from? I recently heard quite an interesting explanation at one of the MBA lectures at the WSB Academy, where it was mentioned that our models are based on three key life experiences – family, school, and church. Hence, the common disorders of many organizations are paternalism, servility, and preaching (meaning “I, the boss, say so, so that is how it is and that is what you are to do. If you think differently, see point one”).

In the execution of IT projects, a classic attitude is seen to be a “waterfall” model, where the work is carried out top-down, beginning with detailed analysis, development of a WBS (Work Breakdown Structure) diagram, Gantta, schedule, then implementation, tests, etc. This model differs to the currently popular scrum in that in scrum this whole cycle comes under one sprint which takes between one and four weeks. This is, of course, greatly simplified, but I won’t go int detail now, because the subject is rather common knowledge.
I have the sporadic pleasure of taking part in the recruitment of Project Managers, and I am constantly surprised by the lack of awareness of the foundations of this framework (regardless of its popularity), even – what’s worse – a lack of awareness of where lies the most significant scrum knowledge. Project Management Institute has their PMBOK, and where is scrum written up? In the “Scrum Guide”, by Ken Schwaber and Jeff Sutherland, for which the Polish version from November 2020 is titled “Przewodnik po Scrumie”, and has a mere 18 pages. It is a sin not to read this short and concise guide. In turn, key elements of an agile attitude are presented in the even shorter “Manifest programowania zwinnego” [Agile Manifesto]. I will not go through the individual points, only an illustration to the point which states that a software which works is more important than detailed documentation. I have worked for a partner wo required extremely extensive documentation, resulting in four pages of documents per one page of system source code. The worst thing was that… no one ever read it. When there appeared a need to explain something, people preferred to ask, as opposed to wading through hundreds of pages of text. However, together with the authors of the Manifesto, I must say that documentation is necessary and valuable – where it makes sense and in a rational form/ extent.

A humorous aspect of Scrum is also that very few organizations use it point by point, from A to Z. Usually, using only chosen elements. The reasons for this are many, among the basic ones it is enough to mention the fact that clients very rarely agree on a contract built fully on an agile model. However, there are usually hard expectations relating to cost, scope, and timing. This already implicates certain changes in the process which must consider given factors resulting from the contract. Although, I personally think that in order to break the rules you must know them well, and you must do it knowingly. If not, we then often have to deal with another, also very common methodology, something which I call “management through chaos”, which often translates to a more advanced model, i.e., “management by fuck-up”.

Another problem is, in my opinion, its frequent erroneous understanding. It manifests itself by an attitude of if the “team is self-organizing”, “we are all equal” etc., then it is enough to present a subject, organize a meeting with programmers and the client, and the work will get itself sorted. It will not, and a meeting between programmers and the client might lead to problems on one or the other side. On one hand, it is not good to isolate programmers from business reality, including the pressure put on by the client, and on the other, it is good to consider that not every programmer will feel comfortable in such a situation, so it may bring more harm than good. As usual, there is no binary  solution (pun intended).

Does the waterfall model really not work, is it really pointless in this day and age? Is an agile attitude or its implementation in the form of scrum a cure-all? Not necessarily, but more about that later.

Management 3.0

A relatively not very popular attitude approach is management 3.0, presented, inter alia, in Jurgen Appelo’s book, “Management 3.0. Leading Agile Developers, Developing Agile Leaders.” It is an attempt to translate an agile approach, which has proven itself in programming, to the management process – in regard to direct management, more than project management.

In the foreword, Ed Yourdon writes: “In a complex world, where users do not entirely know what they should expect from their system, an where every element around them changes everything else during the production of the system, we need a structured [...] approach to developing the boundaries and general framework of the system, although many details will remain unknown and impossible to learn, until an ‘emergent’ approach will allow for their revelation in the right time.
If the above is true in reference to a technical task based on analyzing, designing, and implementing systems – and I strongly believe that it is – then it is also true in regard to management”.

Again, returning to the analogy of playing by rules which we are not entirely aware of, you could say that such a situation is a result of a great complexity of factors which the company functions in. Both the macro and microeconomic ones, as well as from the complexity of the human psyche and emotions. Hence, management 3.0 is based on the theory of complexity. Its key elements include motivating people, empowerment, developing skills, improvement, definition of boundaries, and creating structure.

A digression illustrating matters of complexity in management: Why planning does not work?

When starting a project, we try to plan its execution over time, considering the participation of individual team members. Whoever has been through the process knows that even if we have been through similar projects, many things will happen which we did not take into consideration, which will unfold differently this time. Reasons for this are plenty – even a different understanding of the written up functional requirements, depression of the key programmers caused by covid isolations, the client changing their mind, an oversight by the analyst who did not foresee certain specific cases.

The root of the problem lies in the fact that as people we are used to thinking n a linear manner, assuming simple cause-and-effect relations, meanwhile, the world is not linear. We plan in X -> Y categories, but between X and Y there appears a whole spectrum of things which we did not think about. Casual determinism is a convenient simplification which makes our lives easier, although it raises many problems where more complicated processed come into play. Addressing this problem, we assume time buffers, which help, but… only a little. A good, even classic illustration of this matter are attempts to forecast the weather. Regardless of the great processing power of modern computers and all the scientific progress, we are still unable to foresee the weather effectively, only a few days ahead. It is because of the complexity of the climatic conditions. Another example could be the classic mistake of traders, based on the assumption that if a given sequence of actions caused a given reaction in the past, the same will happen in the future.

 

Crisis management and management democratization

On 24th of February 2022, as a result of Putin’s decision, Russia invaded Ukraine. The following days brought shocking images of the brutal and ruthless attack by Russian forces and the pacification of Ukrainian cities, civilians – including women and children, hospitals. Millions of people were forced to leave their lives from one day to the next, with one bag (or without anything at all), running away abroad, often leaving behind loved ones and possessions, which they will most probably never get back. Europe, which has not seen such scenes since WWII, froze.
The world today is like a system of connected vessels, so the war in Ukraine instantly influenced the neighboring countries, and not only them. All the more severe economic sanctions are hitting Russia. A side effect of this is that companies with Russian capital have experienced profound consequences, also those in western countries. We could analyze the influence of a critical situation on companies and projects, but the thing that struck me most was something completely different.
the tremendous mobilization of a host of private, anonymous individuals who decided to devote their time and money to help the refugees. A multitude of grassroot initiatives appeared in no time, capable of organizing themselves and others into an extremely effective aid movement, from one moment to the next. One place bringing together such activities was the Wrocław Główny train station. Observing hundreds of people selflessly helping all those arriving is an extremely inspiring experience. then again, from the perspective of a people who has dealt with management for years, I would say that it is the essence, an ideal of the agile management 3.0. Although, a better word than “management” is “self-organization”. It is that case, where this model did work perfectly. At a time when state, regional and city authorities incompetently and arduously tried to do something, those people, without any external help, without any outside financing, did everything possible, and even more. Waiting for the refugees were translators, medical workers, veterinarians, a psychologist, people with water, hot food, sandwiches, dry goods, hygiene products. Some people were coordinating these things being handed out, while others were accepting donations from the queue of donors. Someone else created and updated a list of needs. Someone oversaw the social media, where they informed about what is most needed at the given time and what should not be brought in (a delivery chain in the “lean” model, due to very limited storage space). Someone created an app thanks to which there were 60 volunteers were available at the station 24 hours a day. Someone created a Polish-Ukrainian glossary. The dynamics of the situation created the necessity of constant adaptation of the team, which happened immediately, almost instantly. Without any central control, without any structure.

What caused such an amazing implementation of an agile approach by people who (I assume) don’t even know that something like that exists?
In my opinion – motivation + empowerment. The sense that I, Kowalski, can finally do something truly important and meaningful. I am the decision maker, I do not have to wait for the bureaucratic flow to get the “approval”. I can do something for others. Indeed, I can feel like a hero!
Such a situation shows that contrary to the common opinion that the key motivator is money and money – it turns out that there is something else. A sense of purpose of the work performed and the correspondence of this work with life values.
This I sincerely with for all of us. :)

 

Summary

There is no one formula. There is no miracle drug for all the illnesses. There is no one correct manner of management. The task of every manager is to constantly, deeply, and discerningly search for a method which will be most appropriate for their particular situation, organization, business.



Read another article by Kuba Nadolny and find out why Stereotypes are models for how not to think

    Check how we can improve your business