1. Understand the IT Mentality
The Software industry is a mix of science, technology, art, and business. It is quite difficult to navigate there without understanding these aspects on a good enough level. The biggest problem is that the industry itself is quite complex; therefore, best practices are complex too. You need to learn a lot and verify your knowledge by practicing a lot to succeed.
The incredible technology update rate makes it doubly tough. Nothing you learned ten years ago is needed anymore. So you need to learn at an accelerated pace.
Summarizing all the above, we can say that succeeding in the IT field is not based on innate skills or feelings but on hard practical examples. Never ever “follow the gut” or believe solely based on feeling, including yours.
The best practice in adopting new ideas is to verify that somebody did it before and it worked.
If yes, the idea is worth considering. Otherwise, demand a very good and very detailed explanation on how choosing this path makes your team’s life better. If it passes this test, schedule a lightweight proof of concepts project that experimentally proves it fits into your environment.
The important thing to understand here is that there are no right and wrong solutions because there are many ways to solve software problems. However, there are good and bad understandings of the solution.
If a person can clearly articulate idea in detail or draw a link from adopting this solution to the team’s success to persuade other team members, then we can rely on this person’s vision and hope for the high chance of success.
2. Don’t Mix Production and Development Methodologies
Software production is based upon software development. However, these two have completely different goals, mindsets, and practices. Trying to solve a problem from one of these realms with the methods from another produce ridiculous results. It is important to understand the distinction and to use appropriate methods for each of these worlds.
Software development is a combination of art and craft. The art component will always be there regardless of automation tools and methodologies out there. Therefore, solving development tasks requires maximum concentration and shielding from all other distracting signals.
The best way to motivate an experienced developer is to present them a task in its pure technical form with all human factors excluded. All requirements should be also expressed in technical language. They should be easily verifiable to allow them to navigate toward the goal during their solo research phase.
Software production, in contrast, is more in the business administration domain. You know what your customer needs from one side and you know what team resources you have at your disposal from another. So now you try to direct your team efforts to reach the goal. Meanwhile, you can also estimate your progress speed and present a well-versed plan to the boss. The important skills there are understanding your customer’s wishes, understanding your team’s strengths, and communicating formal plans and schedules.
This being said, I’d like to highlight that many roles in software development are working in both of these worlds—in building a bridge between business and technology—such as team leaders, architects, analysts, and project managers. People in these roles should be able to walk easily between two planes of reality and understand when it’s time to talk business and when it’s time for art.
3. Use Persistent Storage as an Extension to Human Memory
Human memory, although amazing in capacity, has its limits. You remember things with unpredictable accuracy and duration, and when you forget, there is no way to recall it at will.
That’s why we use persistent memory storage to move along at a predictable speed. This is not about formal documentation like user’s manuals that you create long after the fact and for other people to use. This is about using documents literally as your memory’s external extension during the work that helps you to go through the process.
CodeoDesk do not encourage people to process a lot of tasks at once. On the contrary, the fewer tasks you have, the better. Not many work situations are truly human-optimized, though, and multitasking may be required and you have to handle it some way. The above trick helps to handle it better.
4. Don’t Waste Time on Formal Time Estimation
No two projects are alike. The next time you do a similar project, you will have different customers, different goals, a different team; maybe even different technologies. Even using standard tools and components, you will still need to customize their configuration and architecture. When you handle software projects, keep in mind than they involve somewhere between 50% and 100% custom work. They require research, discussions, thinking, trials, and other highly unpredictable activities. In practice, you may experience an enormous difference in what appears on the surface to be the same exact project type and what you’ve done before. A new project type, by extension, is almost impossible to estimate exactly.
If it is so unpredictable, than how are project managers supposed to present a project schedule and stick to it?
There is one formal method of doing this described in the literature; namely, to split the whole project into smaller steps, estimate how long each step takes, and then calculate total project length by combining the work length of individual pieces. There is tons of theory behind this method taught in MBA courses.
Unfortunately, though, no amount of math can save it. This method is notoriously inaccurate, to the extent that it is completely unusable and impractical, not to mention how incredibly time consuming it is. I never saw a project manager that was using formal calculation methods without any adjustments, not even among methodological fanatics. Not even when the company strictly imposed such method usage! In fact, the best performing managers use completely different alternative methods, as described below:
A good project manager tunes up their gut feelings by studying and observing lots of past projects.
A good project manager takes notice of the project type, environment, resources involved, organization type, and all other work aspects influencing the actual project length. Of course, nobody needs to learn solely from their own mistakes. Such observations can be done both directly and indirectly; for example, through books or by studying projects done by other people or even by merely passing the knowledge person to person. Such statistical top level knowledge improves personal project schedule navigation.
5. Understand the Cost of Switching Tasks and Juggling Priorities
The human mind is amazingly engineered by nature. Even though it is incredible, it has its limitations. In other words, it designed to excel in particular areas and in a particular type of task.
A developer’s mind is definitely a great asset in software development. Would you, as a project manager, be interested in understanding it better and put it into a position where it performs the best?
Let’s put it in simple terms, avoiding too much theory. Remember, theory only takes you so far before you need to learn from experience, either your own or from others.
The human mind has strong problem solving and idea generation potential. Unfortunately, it is not always possible to tap into this potential, mainly because to support idea generation, you need to keep all pieces of the problem together in your active memory at the same time. That’s why solving complex problems go through a simplification stage when a task is generalized or reformulated to cut out unimportant pieces and to decrease the number of elements kept in memory simultaneously. In other words, we can either solve one very narrow complex problem or multiple simple problems.
Another important human mind trait is its inability to switch between tasks immediately as computers do. Indeed, you cannot just stop thinking about something at will. You can’t immediately start thinking about a new concept at your full speed either. That sort of mental inertia is perfectly illustrated by air traffic control operators. Even though they are looking at the radar and seeing the whole picture, they still need to load it in their memory to operate quickly. It takes ten minutes for a new operator to watch the screen before they can replace the old one at a shift change.
When people experience this kind of “task carousel,” they lose all sense of achievement and realize that this project is going nowhere.
A good manager stands up and shields the team from such minor disturbances by absorbing the emotional shock-wave and converting it into productive future discussion items. That is definitely hard emotionally, but it’s the only way to keep the team in good working rhythm and to let them deliver.
6. Value Team Players
Most IT industry professionals were asked on an interview whether they are good team players or whether they work well in a team. Yet, probably nobody ever saw clear definition for it in literature. Obviously, such a person would contribute to team success in general, but few people can actually define distinctive personal qualities assuring such success.
The first and foremost quality, of course, is an ability to communicate.
Imagine a person with zero communication abilities. Surely receiving no feedback from team members renders them completely useless. This is so obvious that nobody is actually measuring this skill during the interview, which implies that the skill is at a good enough level as long as person can talk well.
Communication is not a binary yes/no skill; it is more of an information transfer window. The wider it is, the faster and clearer the information exchange.
Communication skill is a multiplier for all other skills the person has.
Understanding Strengths and Weaknesses
Let’s focus on another personal quality essential for a team player.
Most people would agree that a team environment should be more friendly than the average surrounding world to foster collaboration and boost productivity. Therefore, it is important for a team to understand each member’s strong and weak areas to distribute tasks properly and to cover weaknesses with strengths. The first step on this path is for all members to honestly measure their skills against each other. Psychologically, this may be tough as we naturally tend to conceal our weak spots from others, protecting ourselves.
This is where the friendly team atmosphere comes to help.
Building trust is a two-man job.
So the new member is expected to play by team rules. Unfortunately, some people cannot lower their guard even in a friendly environment. They behave like lone wolves throughout their whole life. This is stronger than them. Sadly, such attitude doesn’t contribute to team efforts.
7. Focus on Teamwork Organization
There is as little information on teamwork organization as on any previous topic above. Everybody knows that teamwork is better, but how to build and maintain a team remains a mystery. However, even if it is impossible to cover all aspects of team building, we can at least explore few key team building techniques here.
Each IT project is unique. To be successful in it, one needs to learn and master project specifics. They may include both technical and non-technical knowledge. An example of non-technical knowledge could be a personal network for management, customers, technical support teams, etc. Special technical knowledge is additional details on top of general IT skills.
For example, you may need to know Maven to build a project. However, the exact build structure, the location of properties and filtering will still vary per project. As with any type of knowledge, mastering such details takes time; the more time one invests in it, the better they can perform. Time is the most valuable resource you have. You want to keep your team member focused on the same functional area for as long as possible to capitalize on their expertise and develop them even more, thus constantly improving team performance.
Unfortunately, it is not possible to do it indefinitely. From the one side, people may just get bored. From the other side, you are running a risk of losing their expertise, unexpectedly putting your project at risk.
Let’s see if there are ways to cope with the downsides without impeding team performance much.
Most intellectual workers are natural learners. They would like to learn a particular area until they excel in it.
Software development is a chain of complex and creative problem solving. Even though, with industry development, these complex problems get more and more automated, the work doesn’t become easier. It still involves a large amount of art and individual insight, which is very hard to predict and sometimes even harder to wrangle.
Developers are the edge of the weapon. Their concentration is equivalent to the hardness of the weapon’s tip. Increase their focus and you’ll cut through problems like a hot knife through butter. Distract them and you’ll end up clumsily poking at the butter with a blunted stick.
Allowing for a Learning Curve
Knowledge itself is power. This is especially true for such a complex industry as IT. Every task here has its regular cycle: learn, research, implement. The learning phase in particular is invaluable. Not only does better understanding allow better and faster implementation, there are certain knowledge thresholds that must be passed in order to achieve something at all. Of course, there is no point in over-learning either. Each skill should match the production need and not much above it.
The tips and tricks presented above are a subset of effective software production expertise. By understanding and applying them in real life, you’ll improve your production effectiveness little by little. If you think they are largely unconnected and lacking a theoretical base, you are absolutely right. Try out these tips at work to see if they are worth adopting permanently.