Throughout my career, I’ve been involved in numerous software projects, giving me a front-row seat to how things operate at every stage – decision-making, adopting practices, team building, hiring, skill allocation, and more. I noticed that different strategies led to different outcomes. Being passionate about improvement, I began compiling the most impactful techniques and best practices to enhance my work.

Direct observation is a tough and time-consuming way to learn. I wish I could have learned this from books earlier, but I couldn’t find any on the subject. That’s why I decided to share my insights with those seeking this kind of knowledge. Hopefully, it’ll save them years of personal exploration.

This article will show you how to surpass average industry performance by creating robust and reliable software that demands 5-10 times less maintenance. I can confidently say that over the past 10-15 years, my teams and I have consistently exceeded expectations, achieving remarkable success. Our managers couldn’t be more thrilled.

For instance, my team once completed a crucial project in an unbelievably short timeframe, earning us a “High Performance Team” award from upper management. All this without sacrificing evenings or weekends – just regular work hours.

You see, understanding how to effectively produce software is powerful. In fact, it’s like a secret art that few can grasp even when explained simply. But you’ll learn it here for free. Keep reading if you want to be seen as a software production wizard.

Who Benefits From This?

Before we go further, let’s be crystal clear:

This is for those needing a productivity boost. Life isn’t all about productivity, and neither are all software projects. Sometimes performance isn’t the primary focus, so these practices might not apply.

These techniques are most valuable for team leads, architects, and project managers, though senior developers can also find them useful.

Rule No. 1: Grasp the IT Mindset

The IT world is a blend of science, technology, artistry, and business. To navigate it effectively, you need a solid understanding of each aspect. It’s a complex field, and so are its best practices. Success requires dedicated learning and practical application.

The rapid pace of technological advancement makes it even more challenging. What you learned a decade ago is likely obsolete today. Continuous, accelerated learning is essential.

In short, thriving in IT isn’t about inherent talent or intuition. It’s about real-world experience. Never solely rely on “gut feelings,” including your own.

If so, it’s worth exploring. If not, request a thorough and detailed explanation of how it benefits your team. If it passes that test, conduct a small-scale proof of concept to ensure it fits your environment.

The key takeaway: There are no universally right or wrong solutions in software development, just many paths to the same destination. What matters is a shared understanding of the chosen solution.

If someone can clearly articulate their idea, outlining its details and connecting it to the team’s success, we can trust their vision and expect a high likelihood of success.

Rule No. 2: Separate Software Production and Development Methodologies

Software production relies on software development. However, they have distinct goals, mindsets, and practices. Trying to solve problems from one realm using methods from the other leads to nonsensical results. It’s crucial to recognize their differences and apply appropriate methods.

Software development is a blend of art and craftsmanship. Regardless of automation tools or methodologies, the artistic element remains. Therefore, development requires deep focus and minimal distractions.

The best way to motivate experienced developers: Present tasks in their pure technical form, stripped of non-technical factors. All requirements should be technically expressed and easily verifiable, enabling developers to work independently during the initial research phase.

In contrast, software production falls under the business administration umbrella. You understand both the customer’s needs and your team’s resources. Your role is to guide the team towards the goal, estimate progress, and present well-defined plans to superiors. Key skills include understanding customer desires, team strengths, and communicating schedules and formal plans.

It’s important to note that many software development roles bridge the gap between business and technology – team leads, architects, analysts, and project managers. These individuals must seamlessly navigate both worlds, recognizing when to focus on business aspects and when to prioritize the art of development.

Rule No. 3: Leverage Persistent Storage as an Extension of Your Memory

Human memory, despite its vastness, has limitations. We remember things with varying accuracy and duration, and once forgotten, retrieval isn’t guaranteed.

That’s where persistent storage comes in. It’s not about formal documentation like user manuals, created after the fact for others. It’s about using documents in real-time, as an extension of your memory, to navigate the development process.

For non-trivial or collaborative tasks, document your thoughts and plans as you go. Keep it lightweight – no need for formal, branded documents. A company wiki with a dedicated project space works well. Create pages for specific tasks or problems (takes 30 seconds), and update them whenever you have a new idea or discuss it with others.

In meetings, say, “Hold on, let me jot this down,” and spend 10-30 seconds writing it. It doesn’t need to be lengthy, but it should be clear and comprehensive, like transferring the entire idea onto paper. Later, you or anyone else should understand it as well as you do now. This saves time while enabling on-the-fly documentation.

This serves two purposes.

First, it solidifies your progress by etching it in stone. No more worries about forgotten details, repetitive discussions, or renegotiating settled matters.

Second, it frees your mind by offloading the nagging problem. This mental clarity boosts productivity as you move on to the next challenge.

This applies to any task size. Larger projects simply require larger spaces with hierarchical pages that evolve with the project. The key is to set up your documentation space and structure beforehand to facilitate quick idea capture.

For those who appreciate technical analogies, think of your mind as a powerful processor with limited RAM. It can only handle one thing at a time. Documentation acts as your hard drive, storing information while your mind tackles complex problems iteratively. You load the current state from documentation, process it, update code and documentation with your findings, and repeat until completion.

That said, I don’t advocate for multitasking. The fewer tasks you juggle, the better. However, reality often dictates otherwise. This technique helps you manage multitasking more effectively.

Rule No. 4: Stop Wasting Time on Formal Time Estimations

No two projects are identical. Even seemingly similar projects involve different clients, goals, teams, and technologies. You’ll always need customization, whether it’s adjusting configurations or adapting the architecture. Remember, software projects typically involve 50% to 100% custom work, requiring research, discussions, brainstorming, testing, and other unpredictable activities. What appears identical on the surface can be vastly different in practice. Accurately estimating a completely new project type is nearly impossible.

So how do project managers create and stick to schedules if estimations are unreliable?

One formal method involves breaking down the project into smaller tasks, estimating their duration, and adding them up. There’s a lot of theory behind this approach, often taught in MBA programs.

However, no amount of math can salvage its inherent flaw: It’s notoriously inaccurate, often to the point of being unusable and impractical. It’s also incredibly time-consuming. I’ve never encountered a project manager who relied solely on formal calculations without adjustments, not even the most methodologically rigid ones, even when mandated by their company! In reality, the most effective managers use alternative methods like the one described below:

A skilled project manager considers the project type, environment, resources, organization, and all other factors influencing the project’s duration. Of course, learning solely from personal mistakes isn’t necessary. Observations can be made directly or indirectly through books, studying others’ projects, or even word-of-mouth. This high-level statistical knowledge improves project schedule management.

Two important consequences arise from this approach:

First, estimation accuracy improves with experience. No methodology can compensate for a lack of real-world experience. Second, even the best estimations are statistically based. You can estimate that a project might take between four and twelve months. However, it’s crucial to understand that there’s a 50% chance the project will exceed the eight-month average.

Understanding this statistical probability is incredibly powerful. A wise manager would set a twelve-month estimate, exceeding expectations by completing it early. The point is: No one expects strict adherence to a project schedule.

My advice to project managers and their superiors: Stop wasting time on formal time estimation methodologies. Instead, focus on gathering and sharing statistical data about project durations within the company. I’ve seen this approach implemented company-wide, leading to remarkable predictive accuracy.

Rule No. 5: Recognize the Cost of Task Switching and Priority Juggling

The human mind is remarkable, but it has limitations. It excels in specific areas and with particular types of tasks.

A developer’s mind is a valuable asset. As a project manager, wouldn’t you want to understand and leverage it effectively?

Let’s simplify things and avoid excessive theory. Remember, experience, whether personal or observed, is crucial.

The human mind excels at problem-solving and idea generation. However, tapping into this potential isn’t always easy. Idea generation requires holding all the problem’s pieces in active memory simultaneously. That’s why we simplify complex problems by generalizing or reformulating them, reducing the number of elements we need to remember at once. We can either tackle one very narrow, complex issue or multiple simpler ones.

However, this relationship isn’t linear. As the number of simultaneous tasks increases, our problem-solving abilities decline sharply. That’s why we’ve always relied on and will continue to rely on role specialization. Two individuals working on separate tasks will achieve breakthroughs faster than if they try to tackle both tasks simultaneously.

Another key limitation: Unlike computers, humans can’t switch between tasks instantly. We can’t simply stop thinking about something or instantly shift our focus to a new concept at full speed. Air traffic controllers illustrate this mental inertia perfectly. Despite seeing the entire radar picture, they need time to process and internalize the information. A new controller requires ten minutes of observation before replacing their counterpart during a shift change.

What makes it worse is our inability to forget at will. Learned information lingers, gradually fading over time, but still occupying valuable mental space. Unfinished tasks exacerbate this, creating a nagging “unfinished business” feeling. Our brains cling to information marked for “future reference,” hindering new knowledge acquisition.

Now, let’s apply this to a thought experiment.

Imagine ten developers, each working on a distinct task. In a perfect, distraction-free environment, each task would be completed in a specific timeframe. The project’s duration would equal the time required for the longest task.

Now, imagine the same scenario, but with constant task switching for no apparent reason. Every day, each developer receives a new assignment. Let’s make it even more chaotic: Switch tasks every hour. How soon will they finish? Likely never.

The first scenario showcases effective project execution. The second demonstrates project “execution” in the sense that the manager facilitated its demise. Congratulations! This technique isn’t just time-consuming, it also obliterates team morale.

Most people understand this in theory. However, real-world pressure often leads to its immediate dismissal. A demanding boss requesting a progress report or a client inquiring about a feature’s delivery date – any external event can trigger a project manager to scramble, hastily reassigning tasks and juggling priorities, ultimately derailing the project further.

Sadly, this scenario is all too common.

Effective managers shield their teams from such disruptions, absorbing the initial shock and transforming it into constructive discussion points. It’s emotionally challenging, but it’s crucial for maintaining team rhythm and ensuring successful delivery.

Rule No. 6: Utilize Architecture Reviews for System Design Improvement

The IT industry revolves around the concepts of over- and under-engineering. During interviews, everyone agrees that over-engineering is detrimental. It’s an easy answer because the term itself implies negativity. However, true expertise lies in recognizing and preventing over-engineering in its early stages.

Here are some practical tips based on my experience:

Firstly, a solution is considered over-engineered if a simpler alternative can deliver the same functionality. If you’re unaware of a simpler solution, the simplest one you can offer is considered the best until proven otherwise.

In an ideal world, architecture reviews would guarantee optimal solutions. However, reviews require multiple qualified architects, making them impractical or unavailable in many situations. Without peer review, architects are susceptible to common mistakes. Let’s examine these mistakes and their potential remedies.

One common pitfall is designing without a clear business objective. While it’s obvious that any work should tie back to customer satisfaction, company success, or a similar business need, architectures are often designed partially or entirely without one. The reasoning is either absent or boils down to incorporating as many modern technologies as possible.

Instead of fulfilling the customer’s needs, the architect gets caught up in “playing with cool toys.” This is unacceptable in a professional setting, yet it occurs frequently.

Sometimes, the problem lies in the architect’s personality, particularly their obsession with specific technologies or tools. They become fixated on using them without a clear justification or connection to business needs. A similar issue arises when individuals only know how to build from scratch. Any external trigger sends them into a design frenzy, detached from the client’s reality. Even if the initial trigger was valid, their prolonged detachment renders their work less useful.

The solution is straightforward but requires self-discipline. Architects shouldn’t begin designing until they can clearly and honestly articulate the need for it. This need can manifest as a formal requirement, an implicit need for product improvement, or the emergence of new technologies that render the existing design less effective. Regardless of the form, the architect must understand the driving force behind it. This force then serves as the ultimate benchmark for evaluating the design’s quality.

Another subtle issue is “block architecture thinking.” Individuals with this mindset believe a pre-built solution exists for everything. They directly translate functionality into components without considering the overall architecture. They might simply add a component to the system whenever a new functionality is requested. While this might satisfy immediate requirements, it often leaves the system in a disjointed state. The new block might not integrate seamlessly with the existing system in terms of development, support, or even the company’s licensing model. This forces the team to modify the existing configuration or shoehorn the functionality into the current system, resulting in a maintenance nightmare and performance degradation.

There’s no easy fix for this, as system design is an art. Predicting whether to add or avoid a new component is challenging. The best practice is to maintain a backlog of maintenance and architectural issues, conducting periodic reviews of the overall system architecture. These reviews should also consider emerging technologies. Ultimately, the goal of architecture reviews isn’t simply to fix problems but to assess the feasibility of desired improvements and the system’s long-term viability against obsolescence.

Rule No. 7: Value Team Players

Most IT professionals have been asked about their teamwork skills during interviews. However, a clear definition of a “team player” is rarely found in literature. While it implies contributing to team success, the specific qualities that guarantee it are often unclear.

Having observed individuals at different levels and their impact on project progress, I’d like to highlight some personal qualities that contribute significantly to teamwork.

Communication

Unsurprisingly, communication tops the list.

Imagine someone completely incapable of communication. Without feedback or information exchange, they’d be utterly useless. This is so obvious that it’s rarely assessed during interviews, assuming a basic level of competency.

However, communication isn’t binary. It’s more like a bandwidth for information transfer. The wider the bandwidth, the faster and clearer the exchange.

Since this bandwidth varies greatly among individuals, its width becomes a crucial characteristic of a team player. Remember, we’re talking about conveying information, not just smooth talking, encouragement, motivation, or leadership through communication.

Communication style is also irrelevant. Information can be conveyed orally, textually, visually, or through a combination of methods. One can speak quickly or slowly, maintain eye contact and smile, or look away and speak monotonously. Style might influence your perception of a colleague, but as long as you understand their message, any style suffices.

Let’s look at practical ways to identify and assess communication skills.

Communication involves two major aspects. First is the willingness to share information. Some readily share, while others conceal it. This inclination is often natural but can be modified through self-motivation and practice. Generally, an individual’s current information-sharing behavior is a good predictor of their future behavior. This makes it a valuable trait for assessing a candidate’s potential team success.

People who conceal information are easily identifiable. They often offer useless information instead of what’s needed or ask leading questions to deflect and minimize their own contribution. Regardless of their tactics, you’ll end up feeling like you didn’t receive the necessary information or had to exert excessive effort to obtain it.

It’s important to discern intent. Some naturally open individuals might ask clarifying questions to tailor their response effectively. Conversely, those concealing information use questions to steer the conversation away from providing a direct answer.

The second aspect of communication is the ability to adapt to the listener.

People have varying levels of understanding, communication styles, and interest in specific details. Skilled communicators adjust their approach based on the listener’s comprehension, tailoring their response to provide relevant information. They might ask preliminary questions to gauge the listener’s interest and tailor their response accordingly. This adaptability is invaluable, fostering understanding in most situations, unlike inflexible communicators who often find themselves in deadlocks of miscommunication.

Acknowledging Strengths and Weaknesses

Let’s move on to another vital quality of a team player.

Most agree that a team environment should be more supportive than the outside world, fostering collaboration and productivity. Understanding each member’s strengths and weaknesses is essential for effective task allocation and leveraging complementary skills. This requires honesty and self-awareness, which can be challenging as we tend to conceal our weaknesses.

This is where a positive team atmosphere comes in.

New members are expected to embrace this collaborative spirit. Unfortunately, some individuals maintain their guard even in supportive environments. Their ingrained “lone wolf” mentality hinders team efforts.

Identifying these individuals during interviews is straightforward. They never admit to not knowing something. While it’s natural to showcase one’s best qualities and attempt to solve every problem, everyone has knowledge limitations. Our limits shape our expertise. Refusing to acknowledge limits portrays a “Jack-of-all-trades” persona, adept at nothing in particular.

When hiring specialists, avoid such candidates. This arrogant attitude often coincides with another red flag: unwillingness to seek help. The ability to ask for help is paramount to teamwork, facilitating growth and rapid progress. Stubborn individuals drain company resources and time, grappling with tasks indefinitely without seeking assistance. To identify them during interviews, ask a nonsensical question or use a made-up technical term. A genuinely curious person would admit their lack of knowledge and inquire about it. A defensive individual would not, even if you emphasize that there’s no right or wrong answer and that “I don’t know” is an acceptable response.

Rule No. 8: Prioritize Teamwork Organization

Information on effective teamwork organization is scarce. While the benefits of teamwork are widely acknowledged, building and maintaining a successful team remains a mystery. While covering every aspect of team building is impossible, let’s explore some key techniques.

Cultivating Expertise

Each IT project is unique, demanding specific technical and non-technical knowledge for success. Non-technical knowledge might include understanding the network of management, clients, technical support, and more. Special technical knowledge encompasses specific details beyond general IT skills.

For instance, you might need Maven expertise to build a project. However, the specific build structure, property locations, and filtering methods will vary. As with any skill, mastery takes time and effort. Time is your most valuable resource. To maximize expertise and drive continuous improvement, keep your team focused on the same functional area for as long as feasible.

However, indefinite focus isn’t always possible or desirable. Boredom can set in, or the risk of losing expertise might emerge, jeopardizing the project.

Let’s explore ways to mitigate these downsides without sacrificing team performance.

Assign focus areas to team members, enabling them to cultivate expertise. When they reach a satisfactory level within the project’s scope, further investment might yield diminishing returns. Without motivation and challenges, talented individuals become bored and disengaged.

Combat this by providing opportunities for growth elsewhere. Keep them informed about other projects and the company’s technological landscape, presenting new challenges. If their interests align with the project, you reap double the benefits: a challenged team and expanded skill sets. However, any form of self-development is beneficial for combating boredom, even if it doesn’t directly relate to the current project. As long as their minds are engaged, they retain and reinforce existing project knowledge.

When team experts leave, they take valuable expertise with them. One countermeasure is to maintain comprehensive, easily updatable documentation. Remember the “persistent memory storage” concept?

Project managers would ideally duplicate knowledge within the team if possible. Having two experts for every area would be ideal but expensive. A leaner approach involves encouraging most developers to develop expertise in multiple areas, ensuring at least one deep expert for each aspect. Simultaneously, select a few senior members, such as team leads or architects, to develop both breadth and depth of expertise. These individuals interact with all team members and participate in various tasks, gaining a holistic understanding of the project. This way, if one expert departs, the leader can step in, ensuring project continuity until a replacement is found.

Another approach is cross-training developers in related areas. Allow them to observe, learn, and occasionally dabble in their peers’ work. This cross-training shouldn’t be extensive to avoid disrupting their primary focus and hindering productivity. Cultivating expertise through leadership and cross-training creates a safety net against unforeseen circumstances, providing flexibility in resource allocation.

Minimizing Distractions

Software development is a series of complex, creative problem-solving exercises. Despite increasing automation, the work remains challenging, demanding significant artistry and individual insight.

Developers are your sharpest tools. Their focus is the key to their effectiveness. Enhanced focus allows them to slice through problems effortlessly. Distractions turn them into blunt instruments, struggling to make progress.

This cannot be overstated: Non-problem-solving tasks can be tackled with motivation and effort. Problem-solving requires complete detachment from distractions. Achieving this mental state is difficult, and a good project manager creates a quiet work environment both physically and mentally. A developer’s workspace should resemble a sensory deprivation tank.

Physically, this translates to providing closed workspaces. Each team member needs a dedicated area for focused work. Minimize noise and aisle conversations. Utilize emails and chats for quick communication. Conduct large group meetings in closed rooms to avoid disrupting others. This was the norm in traditional office settings.

Unfortunately, the open office trend is gaining traction, even in large organizations. I advise against it. To make matters worse, this trend often encourages in-place team discussions, essentially shouting across rows of desks over other people’s heads. Developers subjected to constant interruptions throughout the day cannot maintain focus, significantly impacting productivity.

Embracing the Learning Curve

Knowledge is power, especially in the ever-evolving IT industry. Every task follows a cycle: learning, research, implementation. Learning is crucial, enabling better understanding, faster implementation, and unlocking new possibilities. Over-learning, however, is pointless. Skills should align with production needs.

Yet, developers are often pressured to prioritize output over learning. Learning is perceived as wasted time because it doesn’t directly contribute to visible progress. While this might seem illogical, real-world pressure often turns managers into demanding figures who insist on immediate output. I’ve heard the phrase “stop learning and start doing something” countless times throughout my career. Effective managers and team leads understand that learning is an integral part of the process, even if it doesn’t instantly move the progress bar.

Creating a High-Performing Development Team

These tips represent a fraction of what it takes to build a high-performing development team. Understanding and implementing them will gradually enhance your team’s effectiveness. If you find them disconnected or lacking a theoretical foundation, you’re absolutely right.

Creating a top-tier development team isn’t a single-discipline endeavor. It demands knowledge and expertise in various areas. Building this expertise is hard work. There’s no magic bullet or single theory that solves everything. Believing in such shortcuts only distracts you from the real goal.

Experiment with these tips in your own work environment. Share your experiences and insights in the comments below, whether you find them valuable or not.