Before starting this article, I would like to extend my thanks for reading, and also my apologies to for not being able to write last week. It was a busy but enriching week at some training where I actually learned quite a few things, I will share them here soon so stay tuned.

I will today release this short article, and expect a longer one towards the end of this week.

---

Have you ever encountered professionals who seem to place importance only on a certain type of knowledge? It's a situation humorously depicted in this comic strip from CommitStrip.

While expertise is certainly beneficial, it's not always a necessity in the market. In the end, we need to ask ourselves the question if we are either “problem solvers” or “executing monkeys”.

The role of engineering professionals is evolving, moving from a sole focus on knowledge to an all-encompassing approach, represented by the “T-shaped” model. The objective is not just to build right, but to build what's necessary. This calls for a blend of product, technical, and interpersonal skills. For leaders, this translates into promoting continuous learning, cross-functional teamwork, and advocating for stepping beyond comfort zones, thereby cultivating a culture that appreciates all facets of everyday work.

T-Shape: A Blend of Breadth and Depth​

The T-shaped model is the idea that everyone should possess a depth of vertical expertise in their preferred area (the vertical bar of the “T”) while also having a broad horizontal understanding of ancillary areas (the horizontal bar of the “T”). This dual focus ensures not only the capability to execute specific tasks but also the ability to see beyond and understand the larger context, ensuring that what is built is truly what is needed and also not selling snake oil.

Vertical Expertise: The Depth​

The vertical bar of the “T” serves as a symbol for an individual's core skill set, demonstrating their domain of deep expertise. It is their specialty, the area where they could be considered an expert or a specialist. This deep expertise is what most people have traditionally concentrated on in their day-to-day professional lives. It's the strength that they bring to the table in their field and what they are known for.

Horizontal Skills: The Breadth​

The horizontal bar symbolizes the broad range of complementary skills outside of one's core expertise. This notably includes:

• Product Sense: An understanding of the product's goals, target users, and market position. This involves empathy towards the user's needs, an appreciation of user experience (UX) principles, and the ability to prioritize features based on user and business value.
• Collaboration and Communication: The ability to work effectively with cross-functional teams, including product managers, designers, and other stakeholders. Clear communication of technical difficulties, solutions, and trade-offs in a way that is accessible to non-technical team members is vital.
• Business Acumen: A grasp of the business context in which the product operates. This includes understanding the competitive landscape, business models, and how one's work contributes to the overall success and strategy of the company.
• Adaptability and Learning: The capacity to quickly learn new skills, adapt to new tools, technologies, and methodologies as required by the ever-changing tech landscape.
• Any & All Technical Knowledge: refers to a wide range of technical skills and understanding that one might need to do their job effectively. It emphasizes the need for individuals to be comfortable with various technologies and able to learn and adapt to new technical tools and methodologies as required.

Benefits of becoming T-Shaped​

Here are the benefits of becoming T-shaped:

• Personal Growth: The T-shaped model encourages continuous learning and adaptation, leading to personal and professional development.
• Enhanced Job Satisfaction: Having a broader understanding of the product and the business can make the work more meaningful and satisfying.
• Increased Marketability: With a diverse set of skills, T-shaped people are more attractive to employers in a competitive job market.
• Job Security: The ability to adapt to new technologies and methodologies also provides more job security in a rapidly changing industry.

Rounding Up​

As you may have noticed, I am not naming development anywhere. T-shaped has already crossed that line, it's not only applicable to technical roles but also to business roles. Where, for example, to take decisions is not only valid anymore to not understand certain parts of the product.

In conclusion, T-shaped embodies the holistic skill set essential in today's dynamic product development environments. By fostering these all-rounded professionals, engineering leaders can ensure their teams are not just executing to spec but actively contributing to the creation of meaningful, impactful products. As we progress into increasingly complex and user-centric markets, the T-shaped approach will undoubtedly become not just beneficial, but essential for success.

Related Articles​

bookmark

What is your stand on the location where you work from? Work location seems to have become a complex subject for companies and employees in the last year. With an imbalance in the demand for local and remote work, the issue merits discussion.

Reflecting on my professional journey, I have had the opportunity to explore various work modalities. From my early days in on-site environments, savoring technical discussions around me, to remote work across different regions, embracing the nomadic lifestyle and thriving in multicultural settings.

Let's delve into this topic further in the article.

Work Location in the past 5 Years​

Let's address an important aspect first. Remote work isn't a novel concept that emerged during the COVID-19 pandemic. In fact, I've been working remotely from various locations including France, Spain, and the USA since 2016. The tools and infrastructure for remote work, however, have definitely evolved over time.

Before the pandemic, the majority of companies preferred on-site operations and invested heavily in office spaces to meet their employees' needs.

However, the pandemic essentially forced a large-scale social experiment in remote work. The majority of us had to adapt to working from home. Surprisingly, it turned out to be quite effective!

However, as the pandemic winds down, there's an increasing push from companies to revert to the pre-pandemic model. Interestingly, many employees are reluctant to give up the benefits of work-life balance they've experienced during this period (less commute, more family time, more personal time, etc).

The different modalities of Work​

Before we delve further into the topic, let's look at the different work models.

• On-Site: This is the conventional work model where employees need to be physically present at a particular location, often an office, to do their work. This means the employee needs to be in the same city as the company at all times.
• Hybrid: This flexible model blends on-site and remote work. Employees might work from home some days and be in the office on others. This usually means the employee needs to be in the same city as the company. Some subtypes include:
  • Weekly days at the office: set days are designated as either on-site or remote.
  • Flexible hybrid: the individual can choose the best place to work at any given moment, but there is a quota for on-site time.
• Remote: Here, employees work from outside the traditional office environment such as from home, a co-working space, or any other location with internet access. This doesn't require the employee to be in the same city as the company. Some subtypes include:
  • Quarterly days: A certain quota needs to be met within a specific timeframe that enables the person to work remotely.
  • On-demand travel: There are instances where travel is needed for significant interactions that require groups of people to collaborate.
  • Full remote: unless it's necessary, the employee doesn't need to travel at any particular time.

As we can see, there are subtle differences that separate a Hybrid from a Remote work model. The deciding factor that differentiates one from the other is the employee's ability to be located in the same city or nearby.

Excuses to go back to the office​

Some of the reasons that can be affecting the current situation:

• Distrust of Employees: Some companies might harbor concerns about the potential lack of productivity when employees work remotely. These concerns stem from the belief that without direct supervision, employees might be more prone to distractions or unproductive behaviors. Working from home introduces a complexity to the monitoring of employees that some companies dislike.
• Cultural Concerns: A strong, cohesive company culture is often considered a key factor in a business's success. Some companies believe that this culture can only be fostered through face-to-face interactions and shared experiences that come with working in the same physical space. They worry that remote work might dilute this culture, making it harder to maintain shared values, facilitate team bonding, and encourage a sense of belonging among employees.
• Performance Changes: The shift to remote work can bring about changes in employees' performance. This is a complex matter as employee performance does not have a single definition, and as we will see later in this article, it can be driven not only by the person but by their environment.
• Office Investments: Companies that have invested substantial amounts of money in their office spaces may feel compelled to make use of these investments. These investments could include not just the physical office space itself, but also equipment, furniture, and other amenities designed to make the office a comfortable, productive environment. The continued payment for office rents, maintenance, and utilities while the space remains largely unused can also be a motivating factor to return to the office.
• Investor Contributions: In an investment landscape, investors often diversify their investments as a risk management strategy. A significant portion of these investments may be allocated to real estate, directly or indirectly, through various investment funds. If the workforce shifts towards remote work, the demand for these office spaces could decrease, leading to potential implications on the return on investment for these real estate investments. Therefore, the trend towards remote work can have a broader impact on the investment community.
• Community Impact: The presence of office districts in cities and towns has resulted in the creation of numerous jobs in various sectors. The local economy in these districts frequently thrives on the regular influx of office-goers. This includes a wide range of businesses such as restaurants, cafés, fitness centers, and retail stores, all of which rely substantially on the footfall generated by employees working in nearby offices. These businesses can be significantly influenced if more people transition to remote work. As the footfall decreases, these businesses may struggle to sustain themselves, leading to potential job losses and broader socio-economic implications.

Debunking Concerns​

Distrust of Employees & Performance Changes​

While personal skepticism can influence views, performance assessments should be driven by solid data. With that in mind, let's delve into some of the available data:

One ground-breaking Stanford study on the subject, which included 16,000 participants, found a marked increase in remote employee output—even for employees who only worked from home a few days a week. During the study, the telecommuting group displayed a 13% average improvement in performance over the office-based control.

Source

While we possess this data, it's important to note that our employees' performance can fluctuate between different work modalities.

In both Remote and On-site work environments, everyone operates under the same modality, thus establishing a unified workflow. Conversely, the Hybrid mode can introduce complications. This is due to certain sub-categories that we've discussed, where some individuals are local and others are remote. Such a dynamic can inadvertently impact the performance of remote workers, not through any fault of their own, but due to potential exclusion or differential treatment.

Cultural Concerns​

The cultural concern is normally embodied by the phrase:

There are things that happen in the office, that don't happen in remote

The concept here is that specific discussions occur naturally in a local setting. Hybrid work capitalizes on this by emphasizing the value of office days when such interactions can take place. However, a common concern among hybrid employees is that they spend a substantial portion of their office time on remote calls.

Conversely, effective communication and the right tools are crucial for remote work to ensure these interactions can be replicated. This is an area many companies are still struggling to address effectively.

Office Investments​

Investments, particularly in real estate, are often expected to grow over time; hence they can be complex. It's essential to distinguish companies between two groups based on their ownership of the space:

• Owners: As outright owners of the physical space, this asset is a key component of their balance sheet. Naturally, they'll want to maximize its value, as it directly impacts their valuation.
• Renters: With temporary ownership, the space represents an ongoing cost that they need to manage. Minimizing this cost can significantly enhance their profit margins.

As you might expect, each group has a distinct focus. On-Site will likely appeal to Owners, while Remote will be more beneficial for Renters.

As you can see and

Addressing Remote Concerns: Make Remote Work​

From our observations, the primary concern stems from the absence of a unified approach and a shared workspace.

As a company, to surmount these challenges, we can adhere to a few key principles:

Remote First​

The guiding principle of this work model is:

If one person is remote, everyone is remote

This approach aims to treat all employees equally, irrespective of their location. Every process, ranging from meetings to casual conversations, should be designed keeping remote employees in mind. This method ensures that remote workers are not sidelined or disadvantaged compared to their on-site peers.

To this end, investing in the right collaborative tools is crucial so that everyone has the same access and capabilities. Here are some tools you might need:

• Virtual White Boards: Most meetings involve some form of interaction that typically takes place on whiteboards in an office setting. If we use a physical whiteboard in conjunction with a conferencing tool, we risk limiting the involvement of remote participants. Therefore, having a virtual alternative is necessary. A good example of this is Miro, where you can invite people to collaborate live on various types of boards

• Pairing Software: To work efficiently in pair or mob programming, we should simplify collaboration as if everyone were working on the same machine. Code with me from IntelliJ is an example of this.

  https://www.youtube.com/watch?v=Lq0fCMCK-Yw

• Collaborative Knowledge Base: It's important to have a centralized location for team and company information. However, many tools are rigid and lack concurrent editing capabilities. We need to ensure we choose the right tool for our needs. Personally, I've found Notion quite useful.

• Collaborative Documents: Just like our knowledge base, we need the ability to concurrently edit documents like presentations and spreadsheets when preparing for presentations or budget cycles. Google and Microsoft offer robust products with the necessary features.

• Async Communication Tools: All workers need their focus time, so having the right tools for asynchronous communication, including a chat application and traditional email, is essential.

The last three tools are not exclusively for remote work but are important for any work mode.

Virtual office​

Much like a physical office promotes interaction and collaboration, a virtual office offers an online shared space for employees to engage, collaborate, and foster relationships.

This isn't merely about conferencing tools, but about the creation of social environments with virtual desks and communal areas. These tools enable employees to engage in organic conversations when close to another's virtual desk, relax in virtual coffee spaces, indulge in games, and more. Gather.town is a prime example of such a tool.

It's also worth noting the cost-effectiveness of virtual offices compared to traditional physical spaces.

video

Parting words​

Remote work has the potential to be as effective as in-office work, offering employees better work-life balance without compromising the company culture that we hold dear. Like many challenges in our industry, successful remote work hinges on using the right tools. The traditional tools used for in-person work may not be suitable for this new dynamic.

To be candid, hybrid work models often fall short in numerous ways, often representing a compromise rather than an ideal solution. In my view, hybrid models are the most challenging to manage and their impacts are not always evident.

Given this, it's essential that we reassess the paths our companies are taking. We may be inadvertently hindering our own potential due to a few manageable concerns.

[1] https://wfhresearch.com/wp-content/uploads/2024/04/WFHResearch_updates_April2024.pdf

[2] https://qz.com/1627980/remote-work-can-boost-productivity-if-you-have-the-right-tools

I currently feel like the odd one, out. It appears that many people are associating peer review in software with code reviews via pull requests. Do you also share this perspective?

Even before I transitioned into leadership roles, where coding took on a secondary function, I did not engage in pull requests. In fact, I haven't submitted a pull request in a professional context since 2017.

Let's delve into the nuances of the peer review process in this article.

Understanding Peer Review​

Peer reviews, also commonly referred to as peer assessments, involve a rigorous and structured process whereby a professional's work or research is evaluated and critiqued by one or more individuals who possess similar competencies, educational background, and expertise. This concept and methodology of peer review originated and took root in the academic sphere, where it is routinely employed as a critical tool to appraise and judge the value of scholarly outputs and research findings.

The primary function of this system is to serve as a form of quality control, significantly bolstering the credibility, reliability, and overall accuracy of the work that is being reviewed. This is achieved by providing an additional level of scrutiny, thereby eliminating any potential errors or oversight that might have been missed by the original author.

Fundamentally, peer review is a cooperative and collaborative process. It is meticulously designed to enhance the quality of work produced, encourage continuous learning and improvement among professionals, and support the establishment and maintenance of objectivity. It ensures that the work produced adheres to the highest standards of excellence, providing an essential layer of accountability in professional settings.

Software Development Peer Reviews​

Within software development, peer reviews often manifest as code reviews. This involves a developer scrutinizing a software project's source code to identify bugs, errors, or potential enhancements. It's about more than just pinpointing issues—it's also about understanding varied methodologies and learning from colleagues.

Types of Code Review​

I want to emphasize this point, as it appears that the contemporary software development scene may not fully grasp it.

Code reviews aren't always synonymous with Pull Requests 🤯

Let's delve into the alternatives:

Kent Beck has offered a two-dimensional perspective on the types of peer reviews in his article. The two dimensions are:

• Synchronicity: Refers to the timing of the review process. It can occur in real-time as the code is being written (synchronous) or after the author has completed the code (asynchronous).
• Continuity: Considers the workflow in relation to the review process. It can either allow the author to continue working (non-Blocking), or require the author to pause until the review is completed (Blocking).

Let's explore what does each of this peer review means:

• Formal Review: A formal review is a thorough and systematic evaluation of a project, product, or performance. It is often conducted by a group of qualified individuals and follows a specific procedure or set of criteria.
• Pull Request: A Pull Request is a feature in version control systems, like Git, where a developer proposes changes to a codebase. The request is a way to communicate the changes to the team and ask for review and integration into the main code branch.
• Over The Shoulder Review: This is an informal method of code review where one developer looks over the author's shoulder as the latter walks through the code.
• Code Comments: In this approach, developers annotate the source code with comments. These comments offer insights, point out potential issues, and suggest improvements.
• Pair Programming: This is a method where two programmers work simultaneously at one workstation. The “driver” writes the code, while the “observer” reviews each line of code as it's being written.

The Relation Between Feedback Cycle & Waste​

Inherent to the process of peer reviewing is its role as a “quality” gate. As such, many these processes tend to fall into the blocking quadrant of operational procedures. This characteristic of peer reviews can create situations where individuals become idle, waiting for the process to be unblocked. This idle time is not only detrimental to productivity, but can also affect morale and engagement among team members if they span over time. Therefore, it is important to streamline the feedback cycle to minimize these idle periods and maintain efficient workflow dynamics.

In addition, the involvement of a second individual to review the work is also necessary for any type of peer review process. Implying that the longer the feedback cycle between the generation of code and its review, leads to an increase in waste and rework. This is due to the fact that the longer the delay in feedback, the greater the potential for the initial work to diverge from the optimal path, necessitating more significant changes and revisions later on.

Therefore, it is crucial to establish a swift and efficient feedback cycle in peer review processes. By doing so, we not only reduce the likelihood of waste and rework, but also enhance the overall productivity and effectiveness of our teams.

If we take this into account, we want to be as much as possible in the sync & non-blocking quadrant, as the synchronicity causes a small feedback cycle and the non-blocking minimizes the IDLEs.

Debunking Pair Programming Myths​

Why're then we not all doing pair programming?

Pair programming is often misunderstood and associated with numerous fallacies, specially in the realm of efficiency of project resources and velocity. With this in mind, let's review the studies:

• The Costs and Benefits of Pair Programming:

  The significant benefits of pair programming are that:
  • many mistakes get caught as they are being typed in rather than in QA test or in the field (continuous code reviews);
  • the end defect content is statistically lower (continuous code reviews);
  • the designs are better and code length shorter (ongoing brainstorming and pair relaying);
  • the team solves problems faster (pair relaying);
  • the people learn significantly more, about the system and about software development (line- of-sight learning);
  • the project ends up with multiple people understanding each piece of the system;
  • the people learn to work together and talk more often together, giving better information flow and team dynamics;
  • people enjoy their work more.

  The development cost for these benefits is not the 100% that might be expected, but is approximately 15%. This is repaid in shorter and less expensive testing, quality assurance, and field support.

  

• The Case for Collaborative Programming: Teams completed their task 40% faster than the individuals (and this result was statistically significant).

  A field experiment was conducted using experienced programmers who worked on
  a challenging problem important to their organization, in their own
  environments, and with their own equipment. Findings revealed that all the
  teams outperformed the individual programmers, enjoyed the problem-solving
  process more, and had greater confidence in their solutions.

  

• Management Impact on Software Cost and Schedule: Regarding the performance of pairs vs individuals:

  Final project results were outstanding. Total productivity was 175 lines
  per person-month (lppm) compared to a documented average individual
  productivity of only 77 llpm.
  […]
  The error rate […] was three orders of magnitude lower than the
  organization’s norm.

• The Collaborative Software Process: One key finding was that pairs took 15% more developer hours to produce their solutions, but those solutions had 15% fewer bugs.

  An experiment was run in 1999 with approximately 40 senior Computer Science
  students at the University of Utah. Two-thirds of the students worked in
  two-person collaborative teams […]. The other students worked
  independently […] to develop the same assignments. The productivity,
  cycle time, and quality of the two groups have been compared. Empirical
  results point in favor of the collaborative teams […].

Having reviewed the data, it's important to recognize that our industry leans against this technique not due to the data, but for other subconscious underlying reasons:

• The data might seem counterintuitive.
• The available tools are more attuned to a different technique (pull requests).
• Given our inherent social tendencies, there's a psychological aspect to consider that we believe spending too much time with a person is not enjoyable.

Pairing in Other Engineering Roles​

Pairing can be applied effectively in these roles in the following ways:

Design​

In design, pairing can be used for brainstorming, critiquing, and refining design concepts. This includes sketching, prototyping, user testing, and iterating on designs. Pairing helps to bring multiple perspectives to a design problem, leading to more innovative and inclusive solutions.

Product​

In product roles, pairing can be beneficial during product planning, strategy discussions, and execution. Two product managers can collaborate to define the product roadmap, prioritize features, and make decisions based on customer feedback and data analysis. Pairing can lead to more robust product strategies and better decision-making.

Leadership​

In leadership roles, pairing can be used for decision-making, strategic planning, and problem-solving. Two leaders can work together to guide their team or company, make critical business decisions, and navigate complex challenges. Pairing in leadership can foster a culture of collaboration, improve communication, and lead to better outcomes for the team and organization.

Closing thoughts​

Peer review, in software development, is a critical quality control process. It involves evaluation of a professional's work by others with similar expertise, enhancing the work's credibility and accuracy.

However, peer review isn't synonymous with pull requests and can take various forms such as formal reviews, over the shoulder reviews, code comments, and pair programming.

Pair programming, often misunderstood, is an efficient method that reduces errors, improves design, and enhances team dynamics. It can be applied to other roles like design, product, and leadership for brainstorming, refining concepts, strategic planning, and decision-making.

Workplaces operate as complex social ecosystems, with dynamics that reach beyond our immediate coworkers and supervisors to include a broader network of relationships. These secondary connections, which are frequently underestimated, are vital to personal success and the overall effectiveness of an organization.

Have you ever thought about how to manage these second level relationships? This post aims to delve into the concept of second level relations at work and their significance.

Understanding Second Level Relationships​

Second level relations in a work context refers to connections with individuals or groups outside your immediate team, who nonetheless can dramatically impact your work. This includes stakeholders, teams from other departments, service providers, and clients. Much like distant relatives in a family, you may not interact with them daily, but their influence on the work environment can be significant.

These second level relations have a substantial impact on productivity. For example, a good rapport with a key stakeholder could mean faster approvals and quicker project completion. Similarly, positive relations with other teams can foster cross-departmental collaboration, creating a more cohesive and efficient work environment. Conversely, negative relationships could cause problems. That's why it's essential to proactively manage these relationships.

Now, let's categorize and delve into these relationships.

Stakeholders​

A stakeholder can be an individual, group, or organization that has an interest in, or can be affected by, the outcomes of a project or business activity. This can include other employees, customers, suppliers, shareholders who have a stake in the project or organization's success. Stakeholders can significantly influence the direction and success of our projects, as they are the promoters of the needs that we are trying to solve. Maintaining open communication, understanding their needs and expectations, and addressing their concerns proactively can foster a positive and productive relationship.

Other Teams​

These are groups within the same organization but working on different projects or tasks. They may have different goals and objectives, but their actions and decisions can significantly influence the progress of our projects.

Healthy relationships with other teams can facilitate better resource sharing, problem-solving, and collaboration. Miscommunication or disputes with other teams can hinder progress, cause delays and create a challenging work environment. Thus, it's essential to maintain clear communication and mutual respect with other teams.

Providers​

These are the external organizations or individuals who supply goods, services, or expertise that are essential to our projects. This can include everything from software vendors, consulting firms, to freelance experts. Providers can have a significant impact on our project timelines, budgets, and overall success.

If a provider fails to deliver as expected, it can cause delays, increase costs, or even jeopardize the entire project. On the flip side, a reliable provider who understands our needs and reliably meets their commitments can be a key factor in a project's success. Therefore, maintaining good relationships with providers is crucial. This involves clear communication, timely payments, and treating them as partners in our success.

Clients/Customers​

These are the end-users of the product or service we are developing. They can greatly influence our projects, as their feedback and satisfaction often determine the project's direction and success.

Understanding their needs, addressing their concerns quickly, and valuing their feedback are essential for a positive relationship. A satisfied client can lead to repeat business, positive word-of-mouth, and improved reputation, while an unsatisfied client can hinder the project's success.

Determining Importance of relationships​

In assessing the value of relationships, it's key to look at aspects like how often you interact, how interconnected your work is, and their sway in decision-making. By ranking relationships with these factors in mind, you can direct your energies where they'll have the most impact - after all, we can't cultivate every relationship equally.

I typically use Stakeholder Mapping to gauge influence and examine the state of a relationship. You'll find a template in the following image and this link.

To map out the relationships that impact your project, follow these steps:

• Identify Relationships: Make a list of all the 2nd level relationships that have an impact on your project. For example, while the CEO may be a key figure in the company, if they are not directly involved in your project, including them on your map may only complicate things.

  

• Assess Influence: Position these relationships on the influence axis according to how much they affect your project, relative to each other. For example, while the CEO might hold a lot of sway in the company, if they don't affect your project, their influence on you is limited.

  

• Define Relationship Status: Determine whether they are supporting your efforts (Supporters) or hindering your progress (Detractors), relative to each other. For instance, if your main stakeholder is continuously expressing dissatisfaction and losing faith in the project and team, they would be considered a Detractor.

  

• Decide on Areas for Improvement: Choose a few relationships that need attention. These are usually high-influence Detractors that you would want to convert into Supporters.

  

• Revisit and Reevaluate Regularly: Relationships can change over time. It's important to frequently reassess the status and influence of your second-level relationships and modify your strategies as needed.

Improving Relationships​

When relationships that require enhancement have been pinpointed, a variety of specific strategies can be implemented to foster growth and improvement in these areas:

• Empathize: It is crucial to not only understand but also empathize with the concerns, anxieties, and reservations that the other party may have. This involves putting yourself in their shoes and viewing situations from their perspective, which can go a long way in building mutual understanding and respect.
• Be proactive: Rather than waiting for the other party to take action or initiate improvements, it's beneficial to take the first step. This proactive approach shows your commitment to the relationship and can inspire the other party to reciprocate your efforts.
• Improve Communication: Quite often, the root cause of relationship issues is miscommunication or a complete lack of communication. It's essential to understand the communication needs of the other party and act upon them. This could involve being more open, transparent, or timely with your communication, or perhaps adjusting your communication style to better match theirs.
• Build the connections: Beyond the professional capacity, take the time to get to know the person behind the role. Keep in mind that not all factors that motivate a person are work-related. By sharing personal experiences and being open to finding common ground and understanding, you may discover shared interests or values that can strengthen your working relationship. Better interpersonal relationships can contribute to a more cohesive and productive working environment.

Conclusion​

In conclusion, second level relations at work, though not immediately visible, have a substantial impact on an individual's work experience and the overall productivity of an organization. Effective management of these relationships can lead to improved collaboration, smoother workflow, and enhanced job satisfaction. As the work environments continue to evolve, recognizing and nurturing these secondary relationships will become an increasingly important aspect of workplace strategy.

This past year, the buzz word in technology has undeniably been "AI". But what exactly do we mean when we say AI?

Often, our comprehension of terms and definitions can be clouded due to the ambiguity in the language used. A prime example is the term "Artificial Intelligence" (AI). This term used to encompass a broad spectrum of technologies, but recently, it has become largely associated with Large Language Models (LLMs).

What are we talking about?​

AI, in its purest form, is the ability of a machine or computer program to think and learn. It is the theory and development of computer systems able to perform tasks that typically require human intelligence.

Meanwhile, LLMs are defined in this Wikipedia article as:

A language model notable for its ability to achieve general-purpose language generation and other natural language processing tasks such as classification. LLMs acquire these abilities by learning statistical relationships from text documents during a computationally intensive self-supervised and semi-supervised training process.[1] LLMs can be used for text generation, a form of generative AI, by taking an input text and repeatedly predicting the next token or word

It goes without saying that we have yet to reach the real definition of AI, with neither LLMs nor other technologies.

The Psychology of LLMs Hype​

What has made these large language models so intriguing over the past year, prompting such widespread interest?

Their ability to “bullshiting with confidence”. Just try this out yourself, ask any question to an LLM and just tell them they are mistaken and request another option. You'll typically receive an apology followed by an assertive, alternative response.

To clarify, these software models aren't intentionally deceptive. They simply aim to provide responses that align with your queries. Meanwhile, we as recipients are prone to accept information as accurate, especially when it's delivered with apparent confidence. This applies to both machine-generated responses and human communication. Even this paragraph, written by a non-psychologist, likely seems plausible because it's framed convincingly.

So how does an LLM “bullshiting with confidence”. LLMs are trained to recognize patterns in data and make predictions based on these patterns. Essentially, they are statistical functions that predict, given the words in a question, the words that will form a compelling response. This phenomenon of non-accurate but compelling responses goes by the name of hallucinations.

LLMs at the Workplace​

Are LLMs useless? Not at all. Despite the caution required due to the nature of statistically generated responses, these systems can indeed provide substantial value.

Let's explore potential applications:

User-Facing Products​

Interestingly, this technology might just be the first to convince humans they're interacting with another human or an intelligent entity. This opens up new product opportunities where the perceived "human interface" might have more value than the precise accuracy of the content.

Potential applications could include:

• First-tier customer support: By integrating LLMs with user manuals, we could develop a chatbot interface for customers.
• Sales representatives: LLMs could be utilized to create more human-like, machine-driven robot calls or chatbots.

Does this mean human roles will be totally replaced? No, because LLMs lack a true understanding of the problem or the conversation. Therefore, a second level of human intervention remains essential. However, this technology could help businesses scale their operations in a novel way.

⚠️ Personally, I would not use the current technology for products that require accuracy. (example: tax calculations, finances, etc.).

Company Tools​

Typically, businesses possess an extensive amount of data that encapsulates their knowledge base. Filtering this data can be challenging, especially when it's scattered across various systems, making it tough to query. Leveraging LLMs can significantly streamline this process and reduce the mental strain of pinpointing the required information.

⚠️ Keep in mind, LLMs do normally not provide precise responses. Thus, it's crucial to critically assess the answers and cross-reference with the original data for accuracy.

Work Augmentation​

This tool has a wide range of applications that can be incorporated into daily workflows. Let's explore some common utilization.

Writing Assistance

LLMs can provide valuable support in crafting documents, emails, and other written communications. They offer grammatically correct and contextually fitting sentence suggestions, enhancing the overall writing process.

As a general rule, this is a highly productive use of the technology. Just ensure to review the generated suggestions for maximum benefit.

Reference Tool

LLMs can serve as a dynamic reference resource, drawing on the vast expanse of knowledge they've been trained on. They function like a sophisticated search engine, delivering consolidated information.

⚠️ However, as LLMs may not always provide accurate responses, it's crucial to approach the information critically and cross-check with original data sources when necessary.

Coding

Within the realm of coding, LLMs can help in code generation and even in writing documentation. This is possibly the field that can affect most of the readers of this newsletter, so let's do a deep dive on this point.

From my professional experience, we've opted not to utilize this technology so far. The main factors influencing this decision include:

• Quality Inheritance: The quality of code that LLMs generate is directly linked to the quality of the training data. If the model is trained on data that includes poor or flawed code, the generated code will inherit those flaws.
• Cognitive Load: While LLMs can simplify routine coding processes, they can also increase the cognitive burden on developers who need to review and comprehend the generated code, ensuring it meets expectations. Developers may face a choice of accepting the code as-is with potential issues or spend additional time deciphering the proposed code.
• Licensing: Employing LLMs may lead to potential breaches of software licenses. If the model is trained on code under copyleft licenses (e.g., GPL), the generated code could be seen as derivative, thus resulting in licensing complications.

Additionally, upon reviewing the data accumulated over the duration this technology has been in existence, we can observe the following results:

• Supporting Data:
  • Microsoft Experiment: The results were that developers using copilot were able to complete the task 55.8% faster.
  • Pinterest Experiment (Link): They found that their engineers who commit code less often increased their commit rate by 50-100%, and engineers who commit code the most often became about ~40% more productive.
• Detracting Data:
  • Git Clear Research (Link): analyzed approximately 153 million changed lines of code, they found code churn (the percentage of lines that are reverted or updated less than two weeks after being authored) is projected to double in 2024 compared to its 2021, pre-AI baseline.
  • Security Researchers (Link): Explored Copilot's performance on three distinct code generation axes (examining how it performs given diversity of weaknesses, diversity of prompts, and diversity of domains). In total, we produce 89 different scenarios for Copilot to complete, producing 1,689 programs. Of these, we found approximately 40% to be vulnerable.

⚠️ While the technology shows promise, it's not fully developed yet.
Our studies indicate that while short-term productivity may increase, this comes at the expense of code quality. This aligns with the concerns we initially discussed.

Our studies indicate that while short-term productivity may increase, this comes at the expense of code quality. This aligns with the concerns we initially discussed.

As we conclude this article, it's important to highlight the potential vulnerabilities associated with Large Language Models (LLMs) in the workplace. I strongly recommend familiarizing yourself with potential threats and reading more about this topic via the OWASP TOP 10 for LLMs resource.

Conclusion​

The term "Artificial Intelligence" (AI) has recently become synonymous with Large Language Models (LLMs). However, true AI, the ability of a machine to think and learn, has not been achieved with LLMs or other technologies.

LLMs have gained popularity due to their ability to generate convincing responses, but these responses are merely statistical predictions based on input data. Despite this, LLMs can be valuable in the workplace, serving as user-facing products, company tools, and work augmentation. However, caution is advised due to their lack of accuracy.

Lastly, it's imperative that we bear in mind our social responsibility as creators and innovators in the realm of technology. With the current global population standing at 8.1 billion, each decision we make, each technological advancement we introduce, has the potential to impact a vast number of lives. We should, therefore, strive to prioritize the wellbeing of each individual in this global community, ensuring that our contributions to technology are both ethical and beneficial to all.

How much time do you or your team spend on the day to day vs. planing the future? .

I would tend to think that for most this is not a binary situation, as we need to be able to have a plan and deliver on it. For this, we require practicing and intentionally using different types of mindsets. Let’s delve into this deeper in this article.

Balancing Today & Tomorrow​

Working in engineering demands a careful balance between two distinct mindsets: the strategic and the tactical. Understanding these two mindsets and knowing when to apply each is crucial for successful leadership and team performance. Let's delve into what each of these mindsets entails.

Strategic Mindset​

Where do we need to go?

A strategic mindset is forward-looking. It's about setting goals, identifying opportunities, and developing plans to achieve those goals. It involves thinking about the bigger picture and the future direction of the team or the organization, providing a common path for everyone.

An example of a strategic mindset could be considering organizing the company in vertical slices, to define common tools and practices, etc.

Tactical Mindset​

What do we need to do?

On the other hand, a tactical mindset is about the here and now. This involves focusing on the tasks at hand, solving problems as they arise, and executing the immediate steps of any strategy. This mindset is required to survive.

An example of a tactical mindset could be keeping legacy money-making systems running healthy, fixing a bug that affects clients, etc.

Problems of Being Stuck in One Mindset​

Balancing the strategic and tactical mindsets is not an easy task. It requires conscious effort, adaptability, and situational awareness. To lead effectively, engineering leaders must be able to switch seamlessly between these two mindsets, adapting to the fluctuating needs of their team and the project at hand.

If any of the mindsets is dominant, it can lead to issues on a company and team level. Let's discuss the problems of being stuck in each of these mindsets:

Tactical​

Being overly tactical can lead to:

• Lack of bigger picture: Without a strategic approach, leaders might become so focused on immediate issues that they lose sight of broader goals and objectives
• Lost opportunities: A purely tactical approach might miss out on potential opportunities for improvement or innovation, as the focus is solely on dealing with the immediate issues at hand.
• Increased Baseline: Quick fixes might be preferred over sustainable solutions, leading to extra effort of maintenance and the need for extra hands to maintain systems up and running.
• Crisis management loop: A purely tactical mindset can lead to a reactive approach where leaders are constantly dealing with immediate issues rather than planning for the future, keeping the team in a perpetual state of crisis management.
• Burnout: The continuous pressure to handle immediate issues and the lack of preventive measures can lead to increased stress and eventual burnout.

Strategic​

Being overly strategic can lead to:

• Analysis Paralysis: Spending too much time planning and strategizing can lead to indecisiveness, delaying important decisions and actions.
• Missed details: Overemphasis on the big picture might lead to overlooking important details, which can result in faulty execution of strategies.
• Disconnect from the team: Leaders who are overly strategic might lose touch with the day-to-day challenges their team faces, leading to unrealistic plans and expectations.
• Frustration among team members: If leaders are always focused on future plans, team members might feel their immediate concerns are being ignored, leading to dissatisfaction and frustration.

The Role Progression: From Tactical to Strategic​

As engineers progress in their careers and take on more senior roles, there’s often a necessary shift from a primarily tactical mindset to a more strategic one.

• Early Career (99% Tactical, 1% Strategic): Focuses primarily on tactical tasks such as coding, debugging, and learning new technologies. Their work is closely guided by the guidelines set by the bigger picture.
• Mid-Career Engineer (90% Tactical, 10% Strategic): Start to introduce tactical work with strategic thinking to prepare themselves for future work. They are knowledgeable about larger parts of the codebase and product, allowing them to provide input for strategical decisions.
• Late Career Engineer (60% Tactical, 40% Strategic): Continues to execute hands on work, but spends an increasing amount of time on strategic tasks. They make architectural decisions, mentor other engineers, align with other teams engineers.
• Leaders (30% Tactical, 70% Strategic): Spends a significant amount of their time on strategic tasks. They are responsible for planning and coordinating the team's work and ensuring that it aligns with the company's strategic goals.
• Directors (5% Tactical, 95% Strategic): Primarily focused on strategic tasks. They make decisions about the overall direction of the engineering team, manage resources, and coordinate with other parts of the business.
• C-Level (1% Tactical, 99% Strategic): Almost entirely focused on strategic tasks. They set the technological direction of the company, make decisions about the use of resources, and represent the engineering team at the executive level.

Summary​

A strategic mindset focuses on setting goals and planning for the future, while a tactical mindset concentrates on immediate tasks and problem-solving. However, overemphasis on either mindset can lead to issues such as lack of broader vision or missed details. As engineers progress in their careers, there is often a shift from a primarily tactical mindset to a more strategic one, with leaders and executives focusing more on strategic tasks.

I hope this post has helped solve the long-standing question of what is this person doing in their role. And helps also to understand how successful engineering requires a balance between strategic and tactical mindsets.

When you contemplate the structure and effectiveness of your software departments, the concept of product teams and the strategy of vertical slicing emerge as pivotal part of the journey.

These methodologies can revolutionize the way products are developed and maintained, directly impacting their success and the adaptiveness of the organization. This post aims to explore the essence of product teams, their significance, and the practical steps to implement vertical slicing within those teams.

Understanding Product Teams​

A product team is a cross-functional team that includes all the roles necessary to develop, test, and deliver value to the customer. It's centered around a single user need, this will either mean a single product or a closely related set of products.

Value of Product Teams​

1. Enhanced Focus and Agility: Product teams focus on a single product or a set of products, enabling them to rapidly respond to changing customer needs and market conditions. This focus accelerates decision-making processes and product iterations.
2. Improved Accountability: With clear ownership, product teams have a better understanding of their objectives, leading to increased accountability and a stronger sense of purpose among team members.
3. Boosted Innovation: Cross-functional interaction within the team promotes diverse viewpoints, fostering an environment ripe for innovation and creative problem-solving.
4. Customer-Centric Development: Product teams operate with a strong understanding of and alignment with customer needs, ensuring that the products developed truly resonate with and bring value to the end users.
5. Efficiency: Such teams minimize the traditional overhead associated with coordination across different departments, leading to more efficient use of time.

Roles In product teams​

Lets delineate the core skills essential to a product team's success and explain the unique value each contributes to the team's objectives:

• Product Manager: acts as the visionary and strategist of the team. They are responsible for identifying customer needs, setting the product vision, and prioritizing the development roadmap. By ensuring that the team understands the 'why' behind their work, product managers play a critical role in aligning product development with market demands and organizational goals.
• Developers: bring the product vision to life through code. They are the architects and builders of the product, responsible for implementing features, fixing bugs, and ensuring the product's technical viability. Their expertise spans across front-end, back-end, and full-stack development, allowing for versatile problem-solving and innovation.
• Designers: focus on the user interface (UI) and user experience (UX) of the product. They ensure that the product is not only functional but also intuitive, engaging, and accessible to users. By advocating for the end-user's perspective, designers play a key role in making products that are genuinely user-centric.
• Quality Assurance: are the guardians of product quality. They are responsible for identifying and mitigating defects before the product reaches the end-users. Through various testing methodologies, QA engineers ensure the product meets all functional requirements, performance standards, and user expectations.
• Operations Professionals: often including DevOps, focus on the deployment, monitoring, and maintenance of the product in production environments. They ensure that the product's infrastructure is robust, scalable, and secure. By facilitating continuous integration and delivery, they enable the team to release updates quickly and reliably.
• Business Analyst: Serves as the bridge between business objectives and technology solutions. They analyze market trends, assess business processes, and gather requirements to guide the team towards solutions that align with strategic goals. Their insights help prioritize features based on business value and customer impact.
• Data Analyst: Plays a crucial role in informing decision-making through data. They collect, process, and analyze data related to product performance, customer behavior, and market trends. By turning data into actionable insights, data analysts help the team understand user needs, measure product success, and identify areas for improvement.

Incorporating these roles into a product team ensures a comprehensive approach to product development, where strategic vision, technical execution, user experience, quality assurance, operational stability, business alignment, and data-driven decision-making converge to create products that truly meet customer needs and drive business value.

These roles not always need to be different people, nevertheless they are skill that team members need to have or nurture. We could talk here about the T-shapped engineering concept but i am sure you can find deeper knowledge in newsletter and other resources I have published on the past.

Understanding Vertical Slicing​

Vertical slicing refers to the process of breaking down functionalities and features into smaller, manageable pieces that can be developed, tested, and deployed independently. This method contrasts with the traditional horizontal slicing, where projects are divided among different departments or layers (e.g., backend, frontend, database). Implementing vertical slicing necessitates a cultural shift and strategic planning:

1. Redefine Team Composition: Transition from discipline-centric teams (e.g., a backend development team) to cross-functional teams that include members capable of handling all aspects of feature development, from UI design to database management.
2. Adopt Customer-Centric Approaches: Align team objectives and features development with customer journeys and value delivery. Each slice should represent a step towards solving a customer problem or fulfilling a need.
3. Foster a Collaborative Mindset: Encourage open communication and collaboration within and among product teams. This can be facilitated by regular stand-ups, shared goals, and common platforms for project management and documentation.
4. Leverage Agile and DevOps Practices: Implement agile methodologies and DevOps practices to support the rapid development, testing, and deployment of vertical slices. Continuous integration and continuous deployment (CI/CD) pipelines are essential for automating these processes.
5. Train and Mentor: Equip your teams with the necessary skills and knowledge to function effectively in this new environment. This might involve cross-training to ensure that team members can handle multiple aspects of development and operations or specific training in agile methodologies.
6. Measure and Adapt: Establish metrics to measure the effectiveness of product teams and the impact of vertical slicing on product development. Use these insights to continuously improve processes and adapt strategies as needed.

Slicing your organization into product teams​

Most companies will not be organized in this ways so its important to understand how to get there if its our objective. Initiating the transition towards product teams and vertical slicing involves several key steps:

• Define the user journey: Understand the path your user takes when interacting with your product or service. This includes the initial contact, engagement, and long-term interaction. Understanding the user journey helps to identify gaps and opportunities in your product or service.
• Event storming of the value journey: This is a collaborative workflow of brainstorming and problem-solving using sticky notes to visualize the sequence of events in a user journey. This method helps to identify actions and interactions the user experiences.
• Map to existing products: Align the event storming with your existing products. This can provide insights into how well your products fit into the user journey and where improvements or new products might be needed.
• Reorganize ownerships: This involves adjusting team responsibilities to align with the user journey and product mapping. Teams should own certain steps of the user journey to ensure they are focused on delivering value at each stage.
• Re-architecture if necessary: If your current system architecture does not support the user journey and product mapping, consider a redesign. This could involve breaking down a monolithic system into microservices or adjusting your tech stack to better serve user needs.
• Support teams on mentality change: Transitioning to a user journey-focused approach with vertical slicing and product teams requires a shift in mindset. Support your teams through this change by providing training, fostering open communication, and promoting a culture of collaboration.

Conclusion​

By embracing the concept of product teams and implementing vertical slicing within software departments, leaders can create environments that are more agile, innovative, and aligned with customer needs. This approach not only enhances the efficiency and quality of product development but also fosters a culture of collaboration and continuous improvement. As an engineering leader, steering your organization towards this paradigm will necessitate thoughtful planning, commitment, and adaptability, but the resulting advantages can profoundly transform your product development lifecycle.

Raise your hand 🖐️ if you recognize this meme:

Do you agree with it? I generally do. In today's fast-changing tech world, it's easy to get lost in the 'rules' of coding.

It's important that we occasionally stop and rethink our methods—not to reduce the importance of solid coding principles, but to make sure our efforts align with the broader goals of our projects and companies.

Leads Horizons is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

Avoiding the Pitfalls of Dogma & Hype​

Traditional coding practices are the foundation of software development projects. They ensure code readability, maintainability, and scalability. But blindly applying these practices, without considering the project's specific context, can lead to inefficiencies and waste.

For example, being too rigid with certain practices might slow down development in the early stages of a startup, where the ability to pivot quickly is key.

A Real-World Example​

Please take this as an example and not literal agains this specific pattern. I share as its what is fresh in my mind as I've experienced this in at least two workplaces over the last year.

We're currently seeing a lot of hype around Clean Architecture, which involves using the Ports & Adapter Pattern. Well-known figures like Uncle Bob or Vaughn Vernon advocate for it, making it the center of attention.

In many organizations, every single project starts as a Ports & Adapters project, focusing on business logic and separating it from external contact points. While the pattern can be valuable at a code level, we need to consider its drawbacks:

• Starting up: Setting up a Ports & Adapters project takes more initial time, potentially delaying the first release. It may not be the best fit for projects with tight deadlines or a priority on launching a minimum viable product quickly.
• Cognitive load: Ports & Adapters can increase the cognitive load for developers, especially those unfamiliar with the pattern. It might require more training and time for developers to understand and use effectively, slowing down development.
• Over-engineering: The Ports & Adapters pattern can lead to over-engineering, especially in simple projects where such a complex structure isn't needed. This could make the code more complicated and difficult to manage.
• Maintenance: The Ports & Adapters pattern could add more maintenance work. If a project's scope isn't too complex, a simpler architecture might be easier to maintain and evolve over time.

If you have unlimited time or budget, this might not be a concern. But that's not the reality for most new products. Especially in a fast-paced product development environment where you're trying to find product-market fit or experiment with user reactions, this could hinder your profitability.

Aligning Practices with Goals​

Here are some things to consider to align coding practices with your project and company goals:

1. Assess the Project Lifecycle Phase: The needs of a nascent project are vastly different from those of a mature one. Early on, the focus might be on prototyping and rapid iteration. As the project matures, stability and scalability become more important.
   1. Proof of Concept: At this stage, you might prioritize speed over structure. The main goal is to validate your idea's feasibility, so it will be acceptable to take shortcuts in code quality and/or testing.
   2. Minimum Valuable Product: At this stage, the goal is to create a functional product with just enough features to satisfy early customers and provide feedback for future product development. Therefore, while it's important to strive for reusable code, speed and functionality might take precedence.
   3. Minimum Lovable Product: This stage focuses on improving the user experience, making the product more appealing and enjoyable. While maintaining the focus on functionality, you might prioritize refining the user interface, improving performance, or adding features that enhance user satisfaction.
   4. Production Quality Product: At this stage, the focus is on refining the product into a fully-fledged offering that can sustain long-term growth. You might prioritize code quality, extensive testing, and scalable architecture, as the product's stability and performance become increasingly critical.
2. Understand the Business Impact: Consider how the project directly impacts the business. Projects that are critical to revenue or customer experience might require more stringent practices, whereas internal tools might allow for more flexibility.
   1. Team Tools: For tools used by the engineering team, the balance might lean towards speed and functionality. These tools are often used to automate tasks or improve workflows, so they need to work efficiently. Code quality and maintainability can be slightly relaxed, as long as the tool's functionality and performance are not compromised.
   2. Internal Tools: These might include tools for other non-engineering departments. In these cases, the investment normally is not high so there is a need to balance functionality and code quality, maintainability, and scalability.
   3. Client Product: For products that directly touch the client, such as a mobile app or a web platform, the focus might lean heavily towards both functionality and user experience. It is crucial to ensure code quality, maintainability, and scalability to provide a smooth and reliable user experience.
3. Assess Team Abilities: Your team's experience and skills are essential. Consider the potential learning curve when introducing new practices, patterns, or frameworks, as they may not yield the expected results.
4. Balance Risk and Reward: Understand the risk profile of different decisions. For example, skipping peer review process might speed up deployment but increase the risk of bugs in production.

Moving Forward​

As leaders, we need to ensure that our teams aren't following practices just for compliance, but are actively contributing to our company’s objectives. We should foster an environment where questioning the status quo is welcomed, as long as it's with the intent of finding better, more aligned ways to work.

This doesn't mean lowering our standards, but rather adapting them intelligently to better serve our ultimate goals. It's about efficient and effective application, not complete abandonment or blind adherence. Balancing the discipline of coding standards with the flexibility needed to meet business objectives is an art that can greatly influence the success of software projects.

Let’s create a culture that values critical thinking and adaptability as much as coding excellence. By doing so, we not only align our coding practices with our project and company goals but also empower our teams to contribute their best work towards collective success.

Thank you for reading Leads Horizons. This post is public so feel free to share it.

Share

Have you ever read Conway's law before:

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

— Melvin E. Conway, How Do Committees Invent?

And considered how it relates to your experience upon entering a new organization and seeing its entire architecture? We will explore the different levels where Conway's law impacts and how to mitigate its effects if desired.

Conway's Law & Alternatives​

The Status Quo (Conway's Law)​

Conway's Law, proposed by Melvin Conway in 1967, has withstood the test of time. It asserts that a system's design will mirror the structure of the organization that designed it. In other words, if a company has independent teams, the final product will likely consist of distinct components that function independently. Understanding this law can help organizations predict their system architecture based on their internal structure.

If we let Conway's law take the lead, regardless of our system design knowledge, the outcome may not meet our expectations, as we'll see in various layers where Conway's law can influence.

The Other Side (Inverse Conway Maneuver)​

The Inverse Conway Maneuver is a method of restructuring an organization to align better with the desired system architecture, which involves intentionally restructuring the organization to match the desired system architecture. This process can be challenging and disruptive, but it can lead to a more efficient and effective organization.

Key steps to successfully implementing the Inverse Conway Maneuver include:

1. Define the desired system architecture. This should align with the organization's goals and objectives.
2. Analyze the current organizational structure. Identify where the current structure does not align with the desired system architecture.
3. Develop a restructuring plan. This plan should include a timeline and a communication strategy.
4. Implement the plan. This should be done in phases to minimize disruption.
5. Monitor the results. Track the restructuring progress and make adjustments as needed.

Middle Ground (User-Centric Conway Maneuver)​

Conventionally, profitable software is based on user needs. Many organizations claim to be user-centric but fail to organize around them. User-centric Conway Maneuver involves focusing on our client's process and needs, which will impact the organizational structure and systems architecture.

Key steps to successfully implementing the User-Centric Conway Maneuver include:

1. Understand your Target User. This should align with the organization's goals and objectives.
2. Analyze the current organizational structure. Identify where the current structure does not align with the desired system architecture.
3. Analyze the current architecture. Identify where the current structure does not align with the desired system architecture.
4. Develop a restructuring plan. This plan should include a timeline and a communication strategy.
5. Implement the plan. This should be done in phases to minimize disruption.
6. Monitor the results. Track the restructuring progress and make adjustments as needed.

⚠️ Note that any transformation is complex and challenging and should only be undertaken with careful planning and execution.

Layers of Influence​

Conway's Law is not just about high-level architecture; it influences various facets of system design and team collaboration. Here, we detail the layers where Conway's law manifests:

Global Architecture​

At the Global Architecture level, Conway's Law suggests that the technical and non-technical organization definitions can affect your high-level architecture. Let's look at some examples:

• Non-technical departments: In a company with separate marketing and operations departments, the marketing department is likely the primary stakeholder for systems related to the customer funnel, while the operations department is likely the primary stakeholder for systems related to customer care. If there is no communication between departments, your company might make promises it can't keep, or provide a poor customer experience.
• Technical departments: In a company with technical organizational departments where horizontals exist, your teams will reflect that structure. If not careful, you might implement very similar functionalities or overwhelm other teams with too many requirements.

Product Architecture​

In the context of a User-Centric Conway Maneuver, the product architecture level requires you to focus on how the various teams collaborate to deliver a product that fulfills user needs. You need to assess how the teams are structured and how their communication patterns align with the user journey you have defined.

For instance, if you have separate teams for front-end and back-end development, you may need to foster better communication and collaboration between these teams to ensure that your product provides a seamless user experience. This could involve regular cross-team meetings, joint planning sessions, or even restructuring teams to be cross-functional.

Your architecture may have to evolve to support this more integrated approach. For example, you may decide to use a full-stack development approach where each team is responsible for both front-end and back-end development for a certain part of the user journey. This can lead to a product architecture that is more aligned with the user's needs and can adapt more quickly to changes in those needs.

Code Architecture​

At the code level, the User-Centric Conway Maneuver involves considering how the communication and collaboration styles of individual team members can influence the design of system components. This is where the understanding of your target user and their journey can guide the design of individual features or components.

If a developer tends to work in isolation on a feature, this could result in a component that does not integrate well with the rest of the system or does not meet user needs effectively. To address this, you may need to encourage more collaboration and communication within your team.

For instance, you could use pair programming or code reviews to ensure that all team members have input into feature development. This can lead to code architecture that is more cohesive and adaptable, and that better reflects the needs of the user.

Remember, these are just examples, and your actual actions will depend on the specific needs and structure of your organization.

User-Centric Conway Maneuver Action Plan​

You should now be aware that Conway's law can impact your organization unconsciously. Based on our multi-layered view, let's focus on the user-centric Conway maneuver:

Global Architecture​

In this layer, you need to know what your business value is for your users to align to it, as it will likely change the least after you achieve a product-market fit. This knowledge can fuel your organizational and architectural changes. The knowledge required is not technical, but you should at least have defined your target user and their journey.

After defining these models, we will understand the business better, and we can map some new knowledge to reorganize and re-architect. Some possible actions from the examples we saw in the previous section:

• Reorganize Non-technical departments: If there is no communication between marketing and operations, they need to work closer. This could involve having weekly syncs or a common leadership/organization, so their objectives are aligned.
• Technical departments: In the case of horizontal slicing, moving to a more user-centric environment could reorganize teams to be multifunctional and value stream aligned.

Product Architecture​

In the context of a User-Centric Conway Maneuver, the product architecture level requires a focus on how the various teams collaborate to deliver a product that fulfills user needs. This could involve regular cross-team meetings, joint planning sessions, or even restructuring teams to be more cross-functional.

Code Architecture​

At the code level, the User-Centric Conway Maneuver involves considering how the communication and collaboration styles of individual team members can influence the design of system components. This is where understanding of your target user and their journey can guide the design of individual features or components.

Conclusion​

In conclusion, Conway's Law provides valuable insight into how an organization's structure can impact the design of its systems. While the experience and skill of your hires certainly contribute to the quality of work, the architecture of the systems you develop will be significantly influenced by your organizational communication patterns. Hence, you will have to apply the maneuver or none depending on if you accept, mitigate, or want to pivot on the tradeoffs.

Have you ever read Conway's law before:

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

— Melvin E. Conway, How Do Committees Invent?

And considered how it relates to your experience upon entering a new organization and seeing its entire architecture? We will explore the different levels where Conway's law impacts and how to mitigate its effects if desired.

Conway's Law & Alternatives​

The Status Quo (Conway's Law)​

Conway's Law, proposed by Melvin Conway in 1967, has withstood the test of time. It asserts that a system's design will mirror the structure of the organization that designed it. In other words, if a company has independent teams, the final product will likely consist of distinct components that function independently. Understanding this law can help organizations predict their system architecture based on their internal structure.

If we let Conway's law take the lead, regardless of our system design knowledge, the outcome may not meet our expectations, as we'll see in various layers where Conway's law can influence.

The Other Side (Inverse Conway Maneuver)​

The Inverse Conway Maneuver is a method of restructuring an organization to align better with the desired system architecture, which involves intentionally restructuring the organization to match the desired system architecture. This process can be challenging and disruptive, but it can lead to a more efficient and effective organization.

Key steps to successfully implementing the Inverse Conway Maneuver include:

1. Define the desired system architecture. This should align with the organization's goals and objectives.
2. Analyze the current organizational structure. Identify where the current structure does not align with the desired system architecture.
3. Develop a restructuring plan. This plan should include a timeline and a communication strategy.
4. Implement the plan. This should be done in phases to minimize disruption.
5. Monitor the results. Track the restructuring progress and make adjustments as needed.

Middle Ground (User-Centric Conway Maneuver)​

Conventionally, profitable software is based on user needs. Many organizations claim to be user-centric but fail to organize around them. User-centric Conway Maneuver involves focusing on our client's process and needs, which will impact the organizational structure and systems architecture.

Key steps to successfully implementing the User-Centric Conway Maneuver include:

1. Understand your Target User. This should align with the organization's goals and objectives.
2. Analyze the current organizational structure. Identify where the current structure does not align with the desired system architecture.
3. Analyze the current architecture. Identify where the current structure does not align with the desired system architecture.
4. Develop a restructuring plan. This plan should include a timeline and a communication strategy.
5. Implement the plan. This should be done in phases to minimize disruption.
6. Monitor the results. Track the restructuring progress and make adjustments as needed.

⚠️ Note that any transformation is complex and challenging and should only be undertaken with careful planning and execution.

Layers of Influence​

Conway's Law is not just about high-level architecture; it influences various facets of system design and team collaboration. Here, we detail the layers where Conway's law manifests:

Global Architecture​

At the Global Architecture level, Conway's Law suggests that the technical and non-technical organization definitions can affect your high-level architecture. Let's look at some examples:

• Non-technical departments: In a company with separate marketing and operations departments, the marketing department is likely the primary stakeholder for systems related to the customer funnel, while the operations department is likely the primary stakeholder for systems related to customer care. If there is no communication between departments, your company might make promises it can't keep, or provide a poor customer experience.
• Technical departments: In a company with technical organizational departments where horizontals exist, your teams will reflect that structure. If not careful, you might implement very similar functionalities or overwhelm other teams with too many requirements.

Product Architecture​

In the context of a User-Centric Conway Maneuver, the product architecture level requires you to focus on how the various teams collaborate to deliver a product that fulfills user needs. You need to assess how the teams are structured and how their communication patterns align with the user journey you have defined.

For instance, if you have separate teams for front-end and back-end development, you may need to foster better communication and collaboration between these teams to ensure that your product provides a seamless user experience. This could involve regular cross-team meetings, joint planning sessions, or even restructuring teams to be cross-functional.

Your architecture may have to evolve to support this more integrated approach. For example, you may decide to use a full-stack development approach where each team is responsible for both front-end and back-end development for a certain part of the user journey. This can lead to a product architecture that is more aligned with the user's needs and can adapt more quickly to changes in those needs.

Code Architecture​

At the code level, the User-Centric Conway Maneuver involves considering how the communication and collaboration styles of individual team members can influence the design of system components. This is where the understanding of your target user and their journey can guide the design of individual features or components.

If a developer tends to work in isolation on a feature, this could result in a component that does not integrate well with the rest of the system or does not meet user needs effectively. To address this, you may need to encourage more collaboration and communication within your team.

For instance, you could use pair programming or code reviews to ensure that all team members have input into feature development. This can lead to code architecture that is more cohesive and adaptable, and that better reflects the needs of the user.

Remember, these are just examples, and your actual actions will depend on the specific needs and structure of your organization.

User-Centric Conway Maneuver Action Plan​

You should now be aware that Conway's law can impact your organization unconsciously. Based on our multi-layered view, let's focus on the user-centric Conway maneuver:

Global Architecture​

In this layer, you need to know what your business value is for your users to align to it, as it will likely change the least after you achieve a product-market fit. This knowledge can fuel your organizational and architectural changes. The knowledge required is not technical, but you should at least have defined your target user and their journey.

After defining these models, we will understand the business better, and we can map some new knowledge to reorganize and re-architect. Some possible actions from the examples we saw in the previous section:

• Reorganize Non-technical departments: If there is no communication between marketing and operations, they need to work closer. This could involve having weekly syncs or a common leadership/organization, so their objectives are aligned.
• Technical departments: In the case of horizontal slicing, moving to a more user-centric environment could reorganize teams to be multifunctional and value stream aligned.

Product Architecture​

In the context of a User-Centric Conway Maneuver, the product architecture level requires a focus on how the various teams collaborate to deliver a product that fulfills user needs. This could involve regular cross-team meetings, joint planning sessions, or even restructuring teams to be more cross-functional.

Code Architecture​

At the code level, the User-Centric Conway Maneuver involves considering how the communication and collaboration styles of individual team members can influence the design of system components. This is where understanding of your target user and their journey can guide the design of individual features or components.

Conclusion​

In conclusion, Conway's Law provides valuable insight into how an organization's structure can impact the design of its systems. While the experience and skill of your hires certainly contribute to the quality of work, the architecture of the systems you develop will be significantly influenced by your organizational communication patterns. Hence, you will have to apply the maneuver or none depending on if you accept, mitigate, or want to pivot on the tradeoffs.