AI Creator's Path News: Project management dilemmas! What if you strive for perfection too much? Learn the difficulties of leading a team. #Project management #Software development #Management
Video explanation
Hello everyone! I'm John, a familiar face to you when I talk about AI technology. I usually explain the latest AI technology and its complex mechanisms in an easy-to-understand way, but today I'd like to change the topic a little.
The other day, I read a thought-provoking story about a software development site. AI development is also a type of software development in a broad sense, so I think it might be useful to you. In this article, I'd like to share a story about a manager's experience that was a bit bitter but very helpful.
Is project management a "double-edged sword"? Confessions of a manager
What I'd like to talk about today is an experience I, John, had a while ago when I was a development team manager at a company in Silicon Valley. (I'll be telling the story of the author of the original article!)
At the time, I was on a team of incredibly talented engineers -- an elite bunch! -- but the product we were building was a software development tool that had once been incredibly popular but was slowly becoming outdated.
Struggling with large, complex software products
This product was just so big and complicated. To put it simply, it was like a "super-sized bento lunch" with all its functions packed into one. Technically, this is called a "monolithic product."
It was customary to release a major upgraded version once a year, adding new features and fixing bugs that had been found. Some of the products had a mechanism for translating programs written by humans into language that computers could understand (compiler) and the basic components that make the program run smoothly (Runtime Library), tools for creating the screens that users see and the parts they operate (Visual Framework), and an integrated development environment (IDE) ...Anyway, it was a lot of different stuff. Bringing it all together and making it into a complete product was a real challenge.
What was especially difficult was,Platform ShiftThis is the process of making the OS (operating system - the basic software that runs a computer, such as Windows or macOS) compatible with a new version, or making it work on a different OS. Because the product itself is large and complex, changing OS compatibility was a huge job that required the whole team to get involved every time.
The beginning of a tragedy caused by a misunderstanding
Then, one day, our company was acquired by another company that made database-related tools. New management came in, and we middle managers wondered, "What will happen next?" and tried to get used to the new structure with a mixture of excitement and anxiety.
From here on, things start to go wrong little by little.
The new parent company was making tools for handling databases. Our products, on the other hand, were general-purpose development tools for creating a wider variety of software. On the surface, they may look similar in that they are both "development tools," but the complexity of the contents was on a completely different level. To put it in perspective, it's like two "bicycles" that look the same, but one is as different as a simple mamachari bike and the other is like an F1 car. The new management had a hard time understanding this "difference in the complexity of the contents."
"Support two operating systems in six months!" - a reckless order
Then the fateful day arrived. The new management gave some shocking instructions.
"Make your product compatible with both Linux and Mac OS. You have six months to do so!"
Our team couldn't believe our ears. "What?! Are you serious?" We estimated that it would take at least a year and a half just to deal with one OS with the staff we had at the time. Now they were asking us to deal with two OSes at the same time, in just six months...
In the world of software development,Brooks' LawThere is a famous law that says, "Adding people to a delayed software project will make the project even later." In other words, simply adding more people does not mean the project will finish faster. We proposed a plan to avoid this law and somehow shorten the project, but...
The management seemed shocked to hear our estimates of "one and a half years for one OS, three years for two." And, to my disbelief, they said, "It can't take that long! You guys are exaggerating because you don't really want to do it, right?" It sounded as if we were trying to slack off. And then, mercilessly, they set a deadline of "do both in six months."
The manager's conflict and irreparable mistakes
It was impossible to support two new operating systems in six months. It was more than a challenge; it was just reckless. The engineers on my team were really talented, but they were not magicians. Even if we worked nights and weekends, there was no way we could make it in time.Death MarchWe couldn't send our valuable team members off to a "reckless project with no chance of success."
What's more, the situation of being suspected of "Are you lying?" was really frustrating and infuriating.
From my experience in the Navy, I firmly believed that "the most important job of a manager is to protect his subordinates." So I kept arguing with the management in a very strong tone, saying "This plan is reckless! It's ridiculous!" I'm sure my frustration and dissatisfaction were reflected in my attitude.
My direct supervisor used to work at the same company, so he knew very well that this plan was crazy. But he told me, "Well, I know it's difficult, but let's give it a try."
I had no idea at the time that the words "Let's try" would determine my fate, because how could I tell my team members to "try" something that I knew would definitely fail?
What I did and what I should have done
Looking back, the actions I took were completely wrong.
Burning with a sense of justice that I had to "protect my team!", I didn't even pretend to cooperate with the management's plan. On the contrary, I even told the engineers on my team, "This plan is crazy, so you don't need to take it seriously." And I continued to bite back at the upper management, saying, "I told you it's impossible!"
So what should I have done? This is where it gets really difficult.
What I really should have done was to somehowDo your bestEven though I knew it was an impossible plan, I wanted to save face for the management team and protect my team from exhaustion.The middle path" I should have made an effort to find one. It's very difficult, to be sure, but I should have at least tried.
In the end, my immature and emotional response got me fired. Did the project not get completed on time? Of course not. But did that mean I was right to be so stubborn and rebellious that it got me fired? No, it was wrong.
Important lessons learned from this bitter experience
What can we learn from this story? The author of the original article points out some important lessons:
- Being a manager can be a really difficult job at times, and you can find yourself caught in a dilemma that seems impossible.
- Sometimes, rather than insisting that you are right,What's best for the entire organization?There are times when you need to prioritize.
- Protecting my subordinates and following company policy as a member of the management teamA sense of balancebecomes very important.
- Just as you manage your subordinates,Managing your boss well(This is sometimes called "managing up") is also important.
After all, "Whether I am right or not" is not enough, "How can we effectively resolve the situation and move forward?" is far more important. The author concludes by saying that he learned this the hard way.
A word from John
It was a heartbreaking story to read. But these "failure stories" can teach us a lot when we look back on them. In particular, the difficulty of communication between people and the misunderstandings and miscommunications that arise from differences in positions and perspectives are things that are inherent not only in AI development, but in any job.
So if you're a manager in the future, or if you're currently facing a similarly difficult situation, I hope this story will inspire you to pause and think, "How can I proceed more wisely?"
This article is based on the following original articles and is summarized from the author's perspective:
Managing software projects is a double-edged sword