|
Thank you for your detailed clarifications. I feel they are very much in line with my own observations.
Note that having “little idea” is seemingly related to a kind of resistance, the lack of will of getting the ideas, probably related to the fear of leaving their comfort zones or something like that.
We are not monkeys. We are humans. And humans are monkeys, apes, period. This is a proper biological classification for our species. Look, human extreme anthropocentrism is one of the root sources of many fallacies of humankind, including wars and colonial exploitation. And top-level apes other than humans are already quite far from just brute force. And many people are still in the brute force domain. This fact even stronger reinforces the idea of criticizing anthropocentric views.
I do accept your notions of “silent communication” and “behavioral communication” as something more than nonverbal communication or body language. Thank you for this important clarification.
Confucius also advised us not to be angry if others don't know. I surely know. And it's a lot more when it comes to teaching, mentoring, and coaching. It is a lot about tons of patience and having a piece of mind.
“Being angry” is a symptom of being a “newbie” to enterprise coaching. Tell me about that! I would rather say, a good reason for complete disqualification.
Thank you.
—SASergey A Kryukov
|
|
|
|
|
Sergey Alexandrovich Kryukov wrote: probably related to the fear of leaving their comfort zones or something like that
Thank you for your help! Your inference sounds quite reasonable to me.
I just reviewed their conversations in my mind and tried to verify whether they were really in the comfort zone.
The sales manager's strategy was trying to maximize the value gained from existing customers with the so-call "new product". Yet, when the strategy was explained in details, old products were planned to meet requirements of "new customers" (if the goal is to bring more money to the company, this will still be viable in the upcoming a few years), but when being asked "what this 'new product' should be", the answer was not clear nor vivid. Some ways to gather information were provided, for instance, listening to complaints from users, looking for competitors' products according to users' feedback. However, the strategy left a lot aspects unexplained, such as at what time which product should be developed to meet what requirements from which kind of customers with what key features and how much revenue will be gained expectedly? If they hadn't the answer, how would they find it out?
The development manager's strategy was somewhat revised after a recent failure. The strategy was that multiple products would be developed almost simultaneously to fulfill some requirements from some orders of a certain customers, while the situations become favorable, the development and marketing rollout for the most promising candidate product would be boosted by putting more developers and money, and handing that product to the sales department at that time. Before "that time" comes, the sales department need not to get involved (no need to waste their time on promoting immature products). To contact the right customer without the sales department, they had employed a "project manager" last year, who was proven to have more knowledge of product innovation and better technical communication skills than any existing sales representatives. This strategy sounded more complete, but we could still easily raise questions about it within seconds and the answers to the following questions were unsure. How did they meet customers, by plan or by chance? Were those customers and their requirements typical enough that products built upon their orders could scale out to the big market? What were the "favorable" situations? How would they judge which product would be "promising"? If we dig more into the operations of their department, we would find some more questionable aspects, for instance, developing multiple products simultaneously or develop a single product (or two) only, which would be more productive? ...
Those two bunches of questions were really uncomfortable to them.
Sergey Alexandrovich Kryukov wrote: Tell me about that! I would rather say, a good reason for complete disqualification.
My opinions below.
Well, the "angry" might not be necessary being mad at the coached people.
It might just be mentally upset.
Control the feelings, try to find out why others don't understand, heuristically change our expressions with positive emotions and gestures may be the way out.
Having tried all kinds of methods, if the situation is critical and time is limited, being "angry" might still be a way. However, it should be very carefully and scarcely used.
Things are much easier said than done. I was educated by my affectionate parents and many excellent skillful teachers while I grew up with other kids. They had set very good examples for me. While I am about to feel angry, I should think of them.
modified 11-Aug-23 8:46am.
|
|
|
|
|
Thank you for the reply. It's a good constructive reaction to a pretty trivial “comfort zone” idea and a good, interesting analysis.
Having tried all kinds of methods, if the situation is critical and time is limited, being “angry” might still be a way. Well, no, it shouldn't be the way, really. You see, maybe you keep in mind something a bit different.
I think anger is always bad, this is the weakness. But I don't say that some negative behavior should not be the way. A negative situation does require a negative reaction. But it should not be the anger. Even the idea of “controlling your emotions” is not perfect. Your emotion should not be suppressed. Ideally, one needs to analyze the emotion and develop some constructive “cold” course of action. As a side effect, it should also fix the emotions of the teacher and redirect them to the positive feeling of keeping the situation under control.
Well, I do understand that this is some advice that is too easy to give and way too hard to follow. Most of us are just not strong and smart enough to behave correctly and successfully in all cases.
At the same time, the denial of the validity of proper negative reactions is a big misconception. Sometimes, we (rather figuratively) consider it “Western”. I mean, all that permanent “good job!” reaction without criticism just erodes education. This way, the value of feedback is effectively totally lost. This is what I would call “splash the baby out with the bathwater”.
Thank you.
—SASergey A Kryukov
|
|
|
|
|
Thank you for your alert!
The "angry" was another inaccurate translation from part of the Youthhood Fully section in the Book of Change. I think I understand the principle that you've mentioned in the above comments. However, it is very much beyond my capability to clearly describe the critical timing and preconditions mentioned above in English. Maybe I can get more insight about this after more practices. During the practices, I will keep an eye on this and of course avoid being "angry".
Today I reviewed Confucius' mottos about heuristic education. He remarked that the best moment to enlighten a student is when the student has thought hard enough about a problem but found no way out, when the student wants to say something (about the encountered problem or learned knowledge) but can not.
Hmm, the proof of "think/try hard enough" could be explained with another phrase "subjective initiative"--This phrase is believed to be created by our great teacher Mao, and almost every student in China learned about it. And an explanation of this phrase might be "to find, or create, new ways to solve problems but not to be restricted by the conditions".
|
|
|
|
|
The story of "ridiculous case" continued.
Yesterday I sit among the manager teams and the general manager and heard their meeting.
From their spoken words, they somehow got quite frustrated about themselves. They did wish to make a change to the company, but found their capability was not enough. They reached a mutual understanding that they need a consulting company to help them to establish all sorts of business infrastructure (rules and routines in their company) better than an enterprise coach, after contacting the consulting company for quite a few times.
All managers realized that they were not doing good enough and each manager had a plan to improve their own department. Some plan was written down, but some plans were just in their heads.
The sales manager commented that they should maximize the output from the consulting company, since the fee was substantially high, compared to the profits their company earned this year. To maximize the output, they could altogether try their best to write down and improve their plans together, so they could see how they might do in the most hopeful manner, and what they really need from the consulting company.
The general manager knew very well that they did have their plans. However, he remarked that, since their limited knowledge, their best-effort-plans would probably be rewritten after the consulting company was in site; and that they were already so busy at this time, why waste their time? "This idea seemed a patient with little medical knowledge was spending a lot of time on learning medicine and trying to cure himself.", he said. The development manager agreed.
I talked to the general manager after the meeting. "I was very astonished to hear that you said your managers were patients." The job of patients are not to cure themselves, nor to stay in hospital. The patients have their own jobs. When they recover, they will pick up their jobs again and say good-bye to the doctor.
From my point of view, they appeared more like basketball players in NBA. Their jobs were winning basketball matches. Now they were not playing very well, and you consider hiring a coach or foreign aid into your team to help them perform better. Before, during and after that, they were all in the matches. The purpose of making a best-effort-plan could be seen as a good training of their teamwork. I've never heard a professional basketball player ever complained his training was a waste of time.
Their plans were so limited to their own departments. There was little sign of teamwork.
modified 20-Aug-23 9:08am.
|
|
|
|
|
Your case develops into a detective story.
Thank you.
—SASergey A Kryukov
|
|
|
|
|
Days ago, I asked the managers in the "ridiculous" case story and let them choose the role of "Patient" or "Player".
The sales manager and other managers chose "Player".
The development manager, who echoed the general manager's "Patient" viewpoint last time, refused to choose between "Patient" and "Player", but insisted that he did not want any "Coach" who kept asking him questions and training him slowly, but was always a "Student" who had got absolutely stuck and badly needed a "Teacher" to help him out in a short time.
The general manager concluded that it was just a matter of different viewpoints--the "Doctor-patient" view was from the company problems solving angle, the "Coach-Team Player" view was from the organizational management angle, and even "Student-Teacher" view was also acceptable since it could also help solve the problems.
I disagreed with the development manager and the general manager--Great team members care for, challenge, remind and help each other and they actively position themselves in the match, let their best play the best, no one plays in a way that tries to win all scores in his team; whereas, either patients or students care about themselves only. After this meeting, it was unsurprised why developers knew little about how their products got sold and sales representatives knew little about development and the latter felt the development department was from "another company".
I also talked to the sales manager after the meeting privately, who expressed deep worry about the company. They once hoped that the development department could help make something that helped their sales. Unfortunately, the developers focused too much on "cool", "smart" and "intelligent" things, yet basic requirements from the customers--for instance, the stability of the system--were "ignored" or "not very well fulfilled". Whether those things could be sold well in the market was not the developers' first priority and the market forecast was not their strong suite.
I guessed, if they could team up together smoothly, would their performance be greatly improved?
|
|
|
|
|
I would like to see how it looks in real life, not just the way you tell your story.
Don't you think looking at your role as you describe it is more important? “Player”, “Patient”, “Doctor”… but who are you? People faced problems and made a lot of mistakes, we understand it all. But what are you doing? You offer them a kindergarten game, this is what you do. Or do you want to play the role of a phycologist? Or maybe the doctor of a psychiatric clinic? What do you think those managers should think about you? I don't know, it depends on the settings, but chances are, I would tell you: “Please, get out, we would better do without your help. Or perhaps you want to drop all this and start talking business?” How can those people trust you? Did you think about it?
Also, you question if they “could team up together smoothly…?” I would say, the wrong question. Before posing it, you should get back to the root of the problem and ask: “Why should they team up?” At this moment, you base your reasoning on false assumptions. I would understand if you knew that each team does an adequate job, and the problem is somewhere in the middle. But how can you know that? I cannot see it from what you describe.
—SASergey A Kryukov
|
|
|
|
|
Excellent! The two questions are critical and I am also questioning myself about that!
Your first question had already been in my mind, when I wrote down the first sentence about this "ridiculous case".
I am playing a consultant-like role in the company. They can ask me any type of questions if they want to and I will try to answer them or help them to find the answers. I don't participate in their development or sales, yet I have joint some of their meetings and knew part of their history. Last year, one manager had already realized something wrong in their company, and this year more and more managers had the same feelings. However, they were not very sure about the root cause of the problems. Previously few people had even consulted me about product innovation strategies, since things appeared to go well--sales were decent, customers were increasing, new products were developed, until this year, the economy was recessing, problems emerged with financial reports.
In order to address the root of the problems, I suggested them to write down every problems they were facing and join the results together, so they could have a more complete vista about the whole picture. Problems were enumerated, and we got the following facts:
1. Requirements came from three sources: sales representatives, the product consultant or representative of the development department, and finally the general manager.
2. Requirements were recorded in the development department.
3. It was the development department and the general manager who decided whether a requirement would be implemented, usually, prioritized by the amount of money in the orders.
4. Requirements came from product consultant of the development department were not evaluated by the sales department.
5. About ten products were developing or had been developed, yet only two of them were sold by the sales department.
6. The sales department had no idea about what were on the development schedule or had been developed.
7. Sales department manager or members were seldom invited to join any meetings held during development, except those being sold; developers occasionally join weekly meetings in the sales department.
8. Whether a product had become "mature for market rollout" was determined by the development teams. No product was handed to the sales department yet.
9. Development department had employed their own sales representatives to contact "customers that were unreachable by the sales department".
10. The revenue generated from the development department and their sales representatives were even not enough to pay their salary. Yet the number of the members had almost doubled in one year.
11. It was reckoned that less than 20 percent of development force was used to develop products sold by the sales department.
12. On every managers' meeting, when the sales manager reported problems of a system, the development department seldom voluntarily offered their help, instead, similar systems were purchased as substitutions to the one developed by the development department; the reports presented by the development department had seldom mentioned metrics about feature usage statistics, customer satisfaction, customer activity, despite my suggestions to do so--nevertheless, they did collect usage data and respond to customer feedbacks.
13. Developers and deployment engineers could deduct a percentage from the revenue as their rewards, however, nothing would happen to them if the products were not sold as well as expected.
Some facts/limitations about the company:
1. A small one with less than 100 employers, with limited capital
2. Salary level of the development department is above average in this city, but far below larger cities in our country
3. Developers have received less education than those in larger cities
4. In the market segment of this city, about 50% customers are served by one product/service
5. The sales department and the customer service department contact more than 90% customers and users
Some suggestions I'd given to their general manager before:
1. Focus development force to limited products, do not spread your teams too flat--the development manager also suggested that previously
2. Segment customers and investigate them; Find out common requirements of each segment
3. The goal of customer contact not only include signing the contract, but also finding out the underlying business logic
4. Build your product roadmap with the knowledge gain from the above approaches
5. Evaluate market size and average customer affordability before entrance
6. Keep good watch for your cash flow
7. Show me the above info when you decide to invest more on the project
After the investigations and talks, I guessed I should not sit there waiting for their questions, since not all of them were used to ask, but offer to help them.
modified 21-Aug-23 9:26am.
|
|
|
|
|
Well, great. Thank you for further explanation.
You know, if I had a chance to play your role in this case, I would be afraid the most of one thing: scaring them to death with my criticism... to say the least.
—SASergey A Kryukov
|
|
|
|
|
Thank you for the enlightenment.
I have not ever thought of that
Most of them have been so miserable about their previous failure, but also longing for the consulting company, which is expected to clean up their minds, tell them the ways to solve their problems. The general manager is also my friend. I, frankly speaking, will feel much better for myself, if the consulting company can very well fix their problems for sure. I don't have to be sleepless for their problems any more. However, I hope the final solution can come from themselves, by helping them think more logically and find out the root cause of their status quo, without spending extra money on the fee which could push their company deeper into debt. As a bonus, they can think better about their problems and their customers' problems in the future, promoting their products even better.
Some employees expressed their worries when they heard of the "news":
1. They had no idea what would happen to them, but did feel somewhat panic.
2. Some of them ever had experienced unsuccessful consulting that sank their previous companies so badly, almost to bankruptcy.
3. Some of them might begin to look for another job if "optimization" comes to them.
4. Some managers expected persons outside of the company could help them sort out the problems better, yet some others had so little faith in outsiders.
5. Domestic economy will go worse in the upcoming years. It is not very wise to spend a lot money on things with uncertain payoff.
A manager talked to me in private, remarking that their general manager was so easily driven by "gold apples", or even "golden apples", for several times. With the "golden apples" in his mind, optimism had been maximized, and always consequently led to money loss. That manager tried to warn him about that privately, but failed without any surprise. "You are the only hope now." said the manager.
|
|
|
|
|
I guess, it must be not bad to feel like “the only hope”, but the situation you've described looks pretty depressing.
Not having “to be sleepless” is not a bad thing.
However, I feel like I would try to sort out things, at least for sheer interest and experience. You know, I feel pretty healthy about the episodes of insomnia or overly excited state of mind. To me, the free schedule and general peace of mind easily beat such minor problems.
Some more about my worry, “scaring them to death” and related concerns:
Hippocrates said: Primum non nocere
(First do no harm)
Pretty important, isn't it?
—SASergey A Kryukov
modified 21-Aug-23 14:05pm.
|
|
|
|
|
Thank you for your encouragement.
They eventually decided to hire the consulting company to help them and the general manager assured that they were backed by his money. Fortunately, my payment would not be affected either.
One more manager had realized that they need to study more and began to question other managers to imagine what they would be, if they could keep studying for a month, in their instant messaging group.
As for the "sleepless" symptom, in the view of Traditional Chinese Medicine (TCM), it can be unhealthy, combined with some other situations. I will try to fix it.
TCM is now an argumentative topic in China. It can not be verified by modern science or statistics. However, according to reports and experiences of COVID-19 patients in Wuhan in year 2020 and some of my relatives in year 2022, it seemed to prove that TCM could help them conquer the virus easier and prevent long-COVID dramatically.
modified 4-Sep-23 21:51pm.
|
|
|
|
|
wmjordan wrote: Thank you for your encouragement. … Fortunately, my payment would not be affected either.
Ha-ha, you live a funny life.
wmjordan wrote: …sleepless symptom, in the view of Traditional Chinese Medicine (TCM)…
By the way, I've used TCM by prescription occasionally, as our family uses some help from a Chinese therapist. However, nothing related to sleep — if you take it correctly, it cannot harm your health. I recently had some episodes due to new exciting developments on Solution structures. I'm in an active Code Project authoring phase right now.
Please take a look at this
GitHub repository
The code is complete, and I plan two big articles, but the topics are shown in the short repository description.
You may find it strategically important. The idea is: Microsoft focuses on pleasing the starters, and that is a perfectly reasonable approach from the marketing standpoint, but the default Visual Studio templates are not only unsuitable for multi-project fully-fledged solutions but are simply unacceptable. But I provide an easy fix.
Thank you.
—SASergey A Kryukov
|
|
|
|
|
Actually I paid little attention to the VS solution structures previously.
I'll be looking forward to your articles.
|
|
|
|
|
Not paying attention? Let's say a simple thing: you have a solution of 20 projects. What do you do to assign a version and attributes like Product? Every time, visit every project and paste the values from the clipboard. If some of the projects should be targeted essentially to net7.0, and some to net7.0-windows, what would you do? How do you know what files should go to revision control and what not? I'm just curious, to get an idea on what people think...
Thank you.
—SASergey A Kryukov
|
|
|
|
|
I do have a solution with many projects. But those projects were not added to the solution at a time.
I developed one project, then another project, then more when it is required.
Version numbers and the "year" in the CopyrightAttribute are automatically generated and incremented with an extension in VS (in teamwork, this can also be automated or done by the one who is responsible for release). Attributes like ProductAttribute are added once and left alone afterwards. So to the project targets.
All those things are created one by one and seldom change.
Compared to the time spent on developing and debugging, the above stuff is nothing.
"Revision control", or "version control" your meant?
If it is "version control", all our code files and markdown documentations are in version control.
|
|
|
|
|
I don't think you understand important things. As to revision control, I found that a good number of authors tend to put trash under revision control. Some even don't know exactly which files are source files and which files are intermediate and not the author's files. One problem with Microsoft is that the default project and solution templates don't isolate them.
(I was talking about Revision Control Systems — this is the most widely accepted terminology.)
The reasoning based on “compared to the time spent” or “all those things are created one by one and seldom change” is extremely destructive. As if things were measured by time spent. How this time can be related to importance? How about the Pareto distribution? It resembles the complaints of engineers about the “uselessness” of all those mathematical uniqueness quantification and existential quantification theorems. Honestly…
Thank you.
—SASergey A Kryukov
|
|
|
|
|
Oh, trash files.
Obj, dist folders had been uploaded to our SVN server years ago, when our developers were almost newbies to it at the time. Having seen that, I told them to always ignore some intermediate folders.
Nowadays we have various .gitignore files. We check our modifications before pushing changes to the Git server. I checked our Git server just now and I was satisfied with the absence of trash files.
What's the importance then?
|
|
|
|
|
The problem is not .gitignore, but the fact that non-source files and source files are mixed up from the very beginning. This is a big defect of Microsoft build in general, more exactly, of the default settings, but MSBuild is a powerful and generally a very good system, so this defect can be easily compensated. However, offering bad defaults is a problem. I think I do understand the reason: from the standpoint of marketing, it makes the most sense to create a product, that can build multiple-project solutions right away — to please the beginners. However, the way it is done is very questionable: they create separate bin and obj directories (per project), and at the end also copy partial outputs all one common output. As a result, a mess of different directories is created: 1) real source code, 2) intermediate files, 3) output. The purpose of different files and directories is not well documented.
Even though it is fine at first, for creation and support of any serious project this situation is simply unacceptable. Fortunately, it is easy to improve, just with one file.
Another thing hard to leave with is how people do versioning. A version is always a result of a decision, otherwise, the policy would defeat the purpose of versions. I can see how people revisit individual *proj files and change them. Same goes when a product name and other metadata properties are changed. In programming, this is called anti-pattern (magic word, magic number anti-pattern), so why it is tolerated in the solution environments? I know why: because some people think that there are no important details... And — back to the entire discussion we had recently — because of the trend to follow established “procedures“, no matter how bad.
Thank you.
—SASergey A Kryukov
|
|
|
|
|
Yes, the mixed files and folders are really a problem. I tend to place output files from various projects into shared folders, if the containing solution has many projects.
However, it is still not a big deal compared with the real world problems we need to solve.
If there is a tool to migrate those output/supporting/intermediate folders and files into a separated place away from the source code and documentation, that will be better.
|
|
|
|
|
This is not a problem with the correct approach: Directory.Build.props at the solution level defines all you need. On deeper levels, it can be overridden. For example, the target framework could be, for example, net5.0 for some projects and net5.0-windows for others. It is impossible to place some attributes in other project files because it is too late, but Directory.Build.props is read early. In particular, the only way to redirect the intermediate output base path in any other place without using Directory.Build.props , because otherwise the intermediate directories will already be created per project, it happens before MSBuild handles any project file, that is changing it would be too late. And so on…
Again, you can find an example in the root of /code of the GitHub repository.
Again, let me reiterate: I consider speculations like “…still not a big deal compared…” as one of the most destructive attitudes. Can you guess why?
Thank you.
—SASergey A Kryukov
|
|
|
|
|
We have not been bothered by this problem then.
Our solutions have not yet been so complicated.
|
|
|
|
|
wmjordan wrote: Our solutions have not yet been so complicated.
How do you know? Every solution with more than one project is already too complicated to pay for Microsoft's sloppiness. By not addressing this problem, you already pay more compared with the case when you address it properly. The minimal thing to do is to add a single file with corrected properties. Otherwise, led by the standard project templates 1) violate the D.R.Y. principle, 2) follow the the anti-pattern “magic word”. Repeated work is only for robots, conceptual understanding — for humans.
Thank you.
—SASergey A Kryukov
|
|
|
|
|
We did spend some time on dealing with project properties and some other stuff within a solution.
However, it did not take us quite a lot of time, and it did not require us to think about it too hard.
It did not affect the performance of our products either.
Even though your new solution could potentially save us some time, it would not add up to too much, since we don't have so many solutions. And many developers in my company do not use VS or C# at all.
We have many solutions which contain just one project or two projects for each as well. The default solution structure provided by VS does not bring too much trouble to us.
Benefit = ((Efforts & time spent in old approach) - (Efforts & time spent in new approach)) * (number of solutions)
The time spent on this discussion about solution structure might be even longer than what we have spent onto adjusting things in existing projects.
It is just like getting into our car. A car may has "keyless entry system"--just open the door and get into the car, with the key in our pocket; another car has no such keyless access, we need to push a button on the car key, then we can open the door and get into the car. "Keyless entry" is great. But without that, it is not so bad for me. Hmm, of course, for some people, "Keyless entry" is a must have for them.
EDIT: Someone noticed that the battery in a "Keyless entry" car key runs shorter than those without that feature. Please think about whether there is any side effect of your solution as well.
|
|
|
|
|