I'm in a principal role at my current company, and like every development team, it's easy to get lost in the constant noise of daily tickets and product roadmaps. The daily drive to "keep the lights on" can obscure the big-picture solutions that bring a medium-sized company to a level where it can stand out, not just among its peers but in the technical industry in general.
Why do development teams fall into ruts? The usual culprits are agile (scrum), product vision, legacy systems, analysis paralysis, poor communication between siloed teams, vanity metrics, burnout culture, and micromanagement. The fact that this list is long underscores how many paths there are to failure. It's a wonder that development teams succeed at all.
I'm not saying my company has these problems; I'm saying that every company doing significant development has all these problems to some degree. Competing goals, human nature, and unintended consequences are a fact of life.
As an individual, it can be challenging, frustrating, and sometimes even demoralizing to be in a situation where the problems are bigger than one person can solve. In these cases, the most an individual can do is return to the self. In the words of Lao Tzu:
"Knowing others is intelligence; knowing yourself is true wisdom. Mastering others is strength; mastering yourself is true power."
The Common Problems
Development teams encounter a standard array of problems daily. It's okay to recognize these problems and respond individually. However, a single individual won't be able to fix everything, and attempting to do so will cause more problems. Once someone has been on a development team long enough to contribute significantly, they've also had the opportunity to be a part of the problem. Fix yourself first!
Agile
Agile is an endless source of debate. The author of this post nailed it exactly: https://news.ycombinator.com/item?id=5406384. Regarding life as a developer or project manager doing agile, do your best to be in it and not of it. Do good work despite the agile process. Manage projects well, no matter what process the current fad is.
Embrace New Ideas
Once a company exists well enough to hire an engineering team, they've already had the great ideas that made them into a company, and their focus turns inward. That's why it's so rare that existing companies get out of their ruts and grow to create new and exciting products.
If I were to pick a company that reimagined itself well, it would be Square. It was a small company focused on making credit card transactions possible for the masses and succeeded fabulously. Now, it is remaking itself again as Block and poised for a quiet surge.
As an individual, re-inventing a company is more significant than even a C-level executive can do alone. However, one can replace legacy systems and convince others to try new things. Itemize the systems that prevent the company from doing better and understand if they need to be fixed or replaced.
Legacy systems that survive the test of time will not address the needs of a re-imagined product. They cannot be fixed and must be replaced if the company wants to be something it is currently.
Back in the 1990s, I witnessed first-hand how IBM's culture contributed to its failure to re-invent itself. I worked at the Utah Supercomputing Institute, where we managed an IBM 390 mainframe and a cluster of IBM AIX (Unix) workstations.
An embedded IBM team tasked with building cluster management software worked with us for three years. The team emphasized using the Rational Unified Process (RUP) and tools. Every iteration involved meetings and reviewing UML and architecture diagrams, followed by "iterations" and more reviews. However, the focus wasn’t on us—the team that managed the clusters and mainframe. Instead, it was always on presenting to IBM "stakeholders," and the software was delivered only as a demo.
The software was never delivered to the team (my team) that would have used it. If IBM had truly solved the issues around integrating mainframes and Unix clusters in the 90s, they would be a very different company today. Watching RUP in action biased me against it as a software development methodology. I believe IBM had a culture of looking inward for validation rather than focusing on customers.
It's also telling that IBM bought Rational Software in 2003, so rather than learning their lessons about reliance on process over product, they doubled down on their mistake.
Other stuff (rewrite)
and analysis paralysis are related. The root of this problem is usually fear. The classical software engineering approach to replacing a legacy system boils down to Understanding Everything in the System and doing a Bug-for-Bug Rewrite. I'm only half kidding. The new code only needs to replace parts of the legacy system, and I would treat legacy systems as black boxes and delete them when the new system works. I don't spend time analyzing 1000s of lines of code work before building a replacement. I would rather watch code work imperfectly and be on the hook to fix it than spend "design" time trying to develop 100% correct the first time.
Communication
Poor communication between siloed teams is standard. Jargon and acronyms help teams to abbreviate communication but serve as a communication barrier when working with others. George Orwell predicted the dystopia of our current time well, but I think he underestimated the pervasive abuse of language that is commonplace in business (https://www.orwellfoundation.com/the-orwell-foundation/orwell/essays-and-other-works/politics-and-the-english-language/).
Fixing communication is a practice, not an event. We need to improve our communication every day with every challenge that arises. How can a single individual identify poor communication and fix it?
Use clear and straightforward language.
Think of better ways to communicate with colleagues.
Instead of "Did you get my ask?" say, "Can you <describe what you want to do for you>?"
Don't ask, "Can we put a pin on it?" when you mean, "I don't think we need to decide that now."
Prioritize Honesty and Transparency
Act toward the common good and not self-interest.
Don't trust the bureaucracy: that document with an approval checkbox at the top doesn't need approval. It needs you to write and share it.
Do everything as simply as you can: speak, write, code, and organize meetings. Complexity makes everything more prone to communication errors.
Communication, Burnout Culture and Micromanagement
These two go together. I was on a Data Engineering team at a previous company; the VP had as a metric to reduce the Jira backlog of the team's reporting tasks, and the company's culture was to drive more reports. When there were problems, senior-level people would dive in and micromanage, which would cause confusion and quality issues, and developers would quit, thus increasing the backlog.
I was unsuccessful at separating myself from the burnout culture and micromanagement because I spent too much time focusing on the working part of the job and too little time on the communication part. Always prioritize communication. A mutual understanding of a problem can save months of wasted work and is the basis for building future success.
留言