My goal is to become a Tech Lead again in my current team, and I believe that writing about the Tech Lead journey will be a good way to reflect on my progress. I also hope it will be educational and insightful for developers like you.

At the time of writing, I've been with this company for about 2.5 months, but this post summarizes my first month working towards becoming a Tech Lead.

Why do I want to be a Tech Lead?

This section explains my motivation for becoming a Tech Lead and highlights factors you could consider when planning your next career move in software development.

My motivation to become a Tech Lead stems from a combination of four key areas:

1. What I enjoy

   Feeling impactful and responsible for both the technical and people-management aspects of projects

2. What I excel at
   Recognizing patterns, analyzing problems, solving complex issues, and optimizing team workflows in software projects.

3. What I want to challenge myself in
   Selecting solutions that align with business goals and making architecture-level decisions that improve long-term scalability.

4. Compensation
   Typically, the more impactful a role is, the better the pay. More importantly, I believe I bring significant value to the companies I work with, and I want to be fairly compensated for that.

Note on #3: I purposefully titled this point "What I want to challenge myself in" rather than "What I want to develop" because challenges excite me more. This distinction is important when I revisit this post for career motivation or when making future decisions.

My Plan to Become a Tech Lead

In my previous job, I became a Tech Lead because I was the most experienced developer, with strong domain knowledge and expertise in software engineering. However, that’s not the case in my current team. This project is also far more demanding in terms of services performance compared to my previous projects.

This presents a new challenge for me, especially since I’d like to assume the Tech Lead role in a relatively short time. So, what's my plan?

Act Like a Tech Lead from Day One

I want to show that I have the skills and mindset required to be a Tech Lead. I also want my teammates to see what they can expect from me, both as a developer and a potential team leader (though I’m not sure they know about my ambition). This is stressful because it involves suggesting changes to people with far greater project knowledge and ingrained work habits. What helps me manage this stress is:

• Determination to reach my goal

• Confidence in my software engineering skills and belief that I can propose valuable ideas

• A history of failed attempts that have made these situations less intimidating

• Acknowledging that I might be wrong, which helps me communicate humbly and listen carefully

But what value can I bring from day one, when I have minimal domain knowledge? Fortunately, programming languages, solid engineering practices, and design patterns are fairly universal. So, I can review code and suggest improvements based on my general expertise.

That’s what I started with, and I received positive feedback for “suggesting a good improvement and bringing fresh energy to the project.” A strong start, I'd say! Code reviews are also a great way to understand team coding practices and what matters most during reviews.

(I was a bit nervous that someone might tell me to ease up on the comments, but no one did. Either my teammates are very patient, or my suggestions were actually valuable.)

Listen, Observe, Identify Problems, and Plan Solutions

My main goal during the first month was to observe the way of working, types of tasks, team dynamics, meet people, and understand the project’s challenges.

Meetings with teammates, the architect, and project managers didn’t provide as much insight as I had hoped. However, I learned about two key challenges:

1. Many bugs were being reported by users.

2. The team lacked initiative, heavily relying on the Tech Lead, who had been moved to another area. (Spoiler alert - that has improved really fast without anyone’s intervention)

In hindsight, it may have been too early to expect major findings. My ability to dig into issues relies on connecting dots, and I didn’t have enough knowledge at that point. However, the positive side is that I broke the ice with my teammates and other colleagues in the company.

Learning the Domain

Domain knowledge is crucial for speeding up feature implementation and problem-solving, so it’s an area I wanted to focus on. However, I must admit that I didn’t make as much progress as I had hoped.

I expected more thorough onboarding into the domain and services my team maintains, but that didn’t happen. In hindsight, I should have requested more detailed onboarding or taken proactive steps to learn on my own.

What I did manage to do was actively participate in feature refinement sessions. My approach in these meetings was to act as a full and equal team member, asking for explanations when I didn’t understand something. This might sound bold for someone new to the team, but I believed I could contribute once I understood the project better.

My questions and paraphrasing revealed that not everyone shared the same understanding of certain problems, and some key details were missed. So, I did manage to add value, even at this early stage.

I encourage anyone onboarding to a new project to adopt the mindset of “I deserve to understand,” as it’s a great way to gain domain knowledge. Many people are too afraid to ask for clarifications, but it’s essential.

Areas for Improvement and Future Plans

As I mentioned earlier, domain knowledge is essential, and I’m not satisfied with my progress in this area. Therefore, it will be my top priority over the coming months. In my previous projects, solving bugs proved to be one of the best ways to gain this knowledge, so that’s how I plan to achieve this goal.

Despite my initial disappointment with bug analysis, I plan to continue efforts to reduce the number of bugs in our project. I’ll organize a brainstorming session to explore strategies for achieving this goal.

This article explores when to use a modular monolith and key considerations for designing one. It also serves as a "teaser" for a project I've been working on for a few months - a modular monolith template/starter written in Python.

When modular monolith is valid

Choosing the right architecture can be challenging, especially when one option becomes the season's buzzword, and the internet claims it's the only valid choice. A modular monolith isn't a silver bullet either. Let's examine its benefits, when it suits a project, and when other architectures should be considered.

Benefits of modular monolith

Clear and fast features implementation

The main characteristic of a modular monolith, as the name suggests, is its independent modules (I'll also call them "components" in this post). A key benefit of their autonomy is the speed of introducing new features. There are no complicated, confusing dependencies between different components, making it easier to understand what needs to be done and implement changes quickly.

Plays nicely with Domain Driven Design

Monolith modules correspond to DDD's modules and/or bounded contexts. This means that DDD offers guidance on what modules a given project should have. Both approaches are commonly used in medium to large-sized projects. Coincidence? I don't think so.

Why is this important? Designing system components such as modules, bounded contexts, or aggregates is always challenging. Teams using the DDD approach often employ techniques like Event Storming or User Story Mapping. The outcomes of these techniques help determine how to split the system into modules.

Architecture prepared for migration to microservices

Since the modules of a monolith create transactional and semantic code boundaries, they are natural candidates to become separate services. By having modules communicate with one another via clearly defined interfaces and committing changes within a single module, the monolith operates similarly to microservices. Implementing a monolith in this way ensures that some of the necessary mechanisms for a microservices architecture are already in place.

Why not simply go with microservices?

I've become a big fan of "dull solutions" because they are generally more reliable, easier to maintain, and faster to implement - qualities that businesses typically expect. A modular monolith is one such "dull solution" that, when implemented correctly, also ensures the system can be easily upgraded with new features.

Ease of introducing changes

Modular monolith is best suited for new or refactored projects with a non-trivial domain.

When starting a new project, you know the least about the domain and business context, so it's rarely wise to implement the system with architectures that make changing component boundaries difficult. In distributed systems, synchronizing changes between multiple services is necessary to maintain proper system functionality. In a modular monolith, you can change boundaries in a single commit.

Distributed systems also introduce added complexity in areas such as observability, security, and communication between components. Configuring these tools and debugging related issues can be time-consuming and hard to justify to the business, whereas these challenges are minimal in a monolith architecture.

Non-scalability myth

Microservices, lambdas, and other distributed system architectures have become almost synonymous with "scalable architectures," leading some to believe that monoliths cannot be used for performant, replicated services. This is, of course, not true. You can scale a monolith because it is a service like any other. You can even configure some replicas to handle specific high-traffic requests and create more replicas of those "services."

But it doesn't fit everywhere

Of course, a monolith is not a silver bullet. At some point, other architectures may be more suitable. I would opt for microservices when:

• There are so many changes implemented in parallel that testing them takes a lot of time and delays releases. This likely indicates significant organizational growth since the modular monolith was introduced, making it easier, cheaper, and better to change the architecture rather than continuously addressing bottlenecks in the release process.

• Some parts of the monolith have very different non-functional requirements, such as scalability, security, or other "-ities." In such cases, it may be better to extract those modules as separate services and use appropriate tools, designs, and infrastructure to meet the specific requirements.

Characteristics of modular monolith

Module responsibility

In the Clean Code approach, every class and function has a clearly defined responsibility. The same applies to modules, though deciding on their boundaries is not an easy task. Do it wrong, and you'll end up with coupled code, making it difficult to implement new functionalities or fixes without changing multiple modules. Do it right, and you'll benefit from fast changes, easier testing, and maintainable code.

What is right and what's not? Let's check with an example of a system that creates simple games for kids and adults. Each game consists of tasks to accomplish, a background story, and instructions. The story and instructions have both text and speech forms.

Initially, the team implemented this with the following modules: adult game, game instructions, and kids game. While some dependencies between the modules are inevitable, the most problematic one is the "generate speech" function defined in the "kids game" module but used by all modules. This can make the function hard to maintain.

After refactoring, this might look like the following:

In the case of very simple games, it may be possible to implement the game module's logic with generic code that is parameterized by the player's type. This approach eliminates the need for a separate game instructions module. However, it's still beneficial to separate the text-to-speech functionality into its own module to facilitate easy use by other modules. This way, the speech generation logic remains encapsulated and reusable across different parts of the system.

Module interface

No matter how hard you try, communication between modules becomes inevitable when implementing a system that involves more than CRUD operations. In the example of the Games System, the game module utilizes text-to-speech functionality.

It's crucial for downstream modules to expose interfaces that hide their internal implementation details, allowing upstream modules to only use those endpoints. This decoupling ensures that a calling component does not need adjustment when changes are introduced in a called component.

The choice of interfaces depends on your approach. These may include services, controllers, commands, events, etc. The key is to commit to using only these interfaces for communication between modules, promoting modularization and maintainability.

Transactional boundary

Deciding whether a module should define its transactional boundary requires careful analysis, as it can introduce complexities into your system. If each module commits only the data it manages, then the system:

• Is more error-prone, as upstream modules still commit their changes even if downstream processing is buggy.

• Has better performance, as downstream request handling may occur in the background.

• Combines the above two characteristics: fewer entities are committed in a single transaction, increasing the probability of conflict-free transactions and eliminating the need for retries or other handling mechanisms to process the request.

To benefit from the mentioned traits, you need to make communication between modules more intricate:

1. Ensuring System Consistency: Addressing system consistency in case of downstream errors is crucial. While upstream processing may succeed even if downstream modules fail, it leaves the system in an inconsistent state that needs handling. Implementing a proper mechanism is essential. This could involve retrying processing, fixing bugs, or finding alternative solutions.

2. Handling "Only Once Processing": Dealing with the issue of "only once processing" is vital. Suppose a request is processed by a handler that triggers multiple downstream processors, some of which succeed while others fail. To address this:

   • Ensure all handlers are idempotent to safely retry downstream operations. While it's often feasible to make a processor idempotent, assuming all can be safely retried poses risks.

   • Retry only the handlers that failed. This is a non-trivial problem but can be addressed using patterns such as the inbox and outbox patterns. These patterns help manage the state and retry logic for failed operations, ensuring that only the necessary handlers are retried.

As you can see, module-bounded transactions can provide profound benefits but at the cost of more complex system. I'd say it's important to discuss the value of the advantages with business people to decide if it's worth complicating the design and maintenance.

It's essential to remember that the decision to separate transactions isn't all-or-nothing. You can isolate transactions in product-critical modules while sharing them in other components. However, transitioning from a shared transaction to separate ones can be challenging, especially if your code lacks clearly defined interfaces.

In the upcoming posts, I'll detail how I tackled various challenges in my hobby modular monolith project. Stay tuned, and feel free to post any comments or questions until then!

The post turned out quite lengthy (again) so here’s what it’s about:

1. Crashing Gunicorn worker - client receives an empty response when blocking I/O operation is executed

2. Initialization of ContextVar in global context - client’s data accessible to other clients

Crashing Gunicorn worker

In the case of my project we were not that much on a hunt for performance gains but wanted to benefit from automatic documentation that FastAPI provides. However, we defined our middlewares and endpoints async but left most of our code synchronous. And that peculiar mix resulted in crashes of Gunicorn workers.

Minimum reproducible example

Here’s a simplified version of our code

import time
from fastapi import FastAPI

app = FastAPI()

@app.get("/")
async def read_root():
   start = time.time()
   # this can be a request sent to another service
   # or any other I/O operation
   time.sleep(30)
   return {f"This took {time.time() - start} seconds to complete"}

What’s important is that there's a blocking operation when handling requests - time.sleep instead of await asyncio.sleep.

When the above application is run via a Gunicorn:

gunicorn -k uvicorn.workers.UvicornWorker 'main:app' -b localhost:8000 -t 30

sending a request results in a quite cryptic error

curl localhost:8000
curl: (52) Empty reply from server

which becomes apparent after checking server logs

[2024-02-27 21:57:53 +0100] [18085] [CRITICAL] WORKER TIMEOUT (pid:18110)
[2024-02-27 21:57:54 +0100] [18085] [ERROR] Worker (pid:18110) was sent code 134!

As you probably guess, that’s caused by the blocking sleep in handling the request which purely by accident is the exact value of Gunicorn’s worker timeout. That is clear in case of such a simple code snippet but may be harder to debug in a production code. In our case handling a request involved exchanging quite an amount of requests with an external service (which is notorious for causing integration problems).

What is exactly going on?

The main process of Gunicorn essentially does 2 things:

1. Forwards requests to it’s workers

2. Manages workers - starts them up, kills if they are not responsive for a specific length of time (yes, the timeout that is passed to gunicorn command), etc.

OK, but the worker is actually alive so why such harsh treatment?

It’s alive but not able to respond to “poking” done by Gunicorn’s main process. Because of the blocking operation the execution control is not handed back to Uvicorn event loop.

Here’s an illustration of what would happen if await asyncio.sleep was used

In that case the execution would return to the event loop which would then call a function that handles the “poke”.

Let’s use the non-blocking operation then:

import asyncio
import time

from fastapi import FastAPI

app = FastAPI()

@app.get("/")
async def read_root():
   start = time.time()
   # this can be a request sent to another service
   # or any other I/O operation
   await asyncio.sleep(30)
   return {f"This took {time.time() - start} seconds to complete"}

The response is then

curl localhost:8000
["This took 30.002015352249146 seconds to complete"]%

and no sign of problems in the server logs

gunicorn -k uvicorn.workers.UvicornWorker 'main:app' -b localhost:8000 -t 30
[2024-02-27 22:40:32 +0100] [21686] [INFO] Starting gunicorn 21.2.0
[2024-02-27 22:40:32 +0100] [21686] [INFO] Listening at: http://127.0.0.1:8000 (21686)
[2024-02-27 22:40:32 +0100] [21686] [INFO] Using worker: uvicorn.workers.UvicornWorker
[2024-02-27 22:40:32 +0100] [21710] [INFO] Booting worker with pid: 21710
[2024-02-27 22:40:33 +0100] [21710] [INFO] Started server process [21710]
[2024-02-27 22:40:33 +0100] [21710] [INFO] Waiting for application startup.
[2024-02-27 22:40:33 +0100] [21710] [INFO] Application startup complete.
[2024-02-27 22:41:53 +0100] [21686] [INFO] Handling signal: winch

Solution, bigger and smaller workarounds

What can be done to avoid such problem:

1. Employ non-blocking operations. This task is challenging with legacy code. Every function leading to the troublesome blockage requires modification, including decorators. This issue intensifies if the altered code must remain compatible with synchronous operations.

2. Run the synchronous code in a threadpool. The below code does not block

import time

import anyio.to_thread
from fastapi import FastAPI
from starlette.concurrency import run_in_threadpool

app = FastAPI()

@app.get("/")
async def read_root():
   start = time.time()
   # this can be a request sent to another service
   # or any other I/O operation
   await anyio.to_thread.run_sync(time.sleep, 30)
   return {f"This took {time.time() - start} seconds to complete"}

This is a great option and Starlette/FastAPI actually uses that “trick” to call synchronous middleware or endpoint. Since web frameworks do it automatically, then it’s also a valid option to give up on asynchronous endpoints if your use case allows it.

3. Get rid of Gunicorn. That may sound controversial but that’s actually a valid option if your app is orchestrated by Kubernetes. In that case Kubernetes manages the “workers” (pods) and Gunicorn doesn’t provide big value.

Initialization of ContextVar in global context

That one was really hard to debug and was caused in big part by how the dependency injection library we use is implemented but it can occur also in case of the code you write yourself. I’ll make the case easier to understand.

Intro: ContextVar in async Python

When processing a request quite often you need to store a state in memory so that it is accessible later in the chain of processing. This could be for example user information (id, email, roles etc.) determined in a middleware based on authentication token and referenced in application or domain code.

Asynchronous code runs, by default, in a single process and thread so if you were to store this data in a global variable, it’d be accessible, or even overwritten by other requests processing.

ContextVar is a solution for such case. It serves the same goal as threading.local and can replace it. The value of a ContextVar will be different for each “chain” of asynchronous processing code

import asyncio
import contextvars

email: contextvars.ContextVar[str] = contextvars.ContextVar("email")


async def get_email() -> str:
   return email.get()


async def set_email(value: str) -> None:
   print(f"Setting email to {value}")
   email.set(value)


async def email_processing(value: str, seconds_of_sleep: int) -> None:
   await set_email(value)
   await asyncio.sleep(seconds_of_sleep)
   print(f"{await get_email()}, expected {value}")


async def main() -> None:
   await asyncio.gather(
       email_processing("value1@example.com", 1),
       email_processing("value2@example.com", 0),
   )

if name == "__main__":
   asyncio.run(main())

This prints

python contextvar_example.py  

Setting email to value1@example.com
Setting email to value2@example.com
value2@example.com, expected value2@example.com
value1@example.com, expected value1@example.com

Using ContextVar is quite easy but, as you’ll see below, it’s still possible to introduce bugs 🙂

Global ContextVar

The bug that we implemented was that one of our ContextVar variable sometimes became global - shared between requests - which caused overwriting data and accessing other users data (thankfully we noticed it before deploying the changes to production).

The following simplified example illustrates the problem:

import asyncio
import contextvars

request_state: contextvars.ContextVar[dict] = contextvars.ContextVar(
    "email"
)


async def app_startup() -> None:
   request_state.set({})


async def process_request(email: str, processing_time: int) -> None:
   state = request_state.get()
   state["email"] = email
   await asyncio.sleep(processing_time)
   print(f"Processing request with {state=}, expected email {email}")

async def main() -> None:
   await app_startup()
   await asyncio.gather(process_request("value1@example.com", 2), process_request("value2@example.com", 1))

if name == "__main__":
   asyncio.run(main())

which results in

python global_context_var.py

Processing request with state={'email': 'value2@example.com'},
    expected email value2@example.com
Processing request with state={'email': 'value2@example.com'},
    expected email value1@example.com

ContextVar’s value is set during application startup which makes it shared with subsequent coroutines and/or tasks. When the state is updated during requests processing, it’s also updated for the other coroutine so instead of value1@example.com the first request is processed with value2@example.com.

Again, it’s relatively easy to spot the problem in the above exemplary code but most of the time there’s a lot of indirection. In our case there were 2 cases:

1. Our dependency injection library uses descriptors which were evaluated during application startup and caused a ContextVar to be initialized (instances of dependencies are stored in the ContextVar)

2. Due to infrastructure problems an exception during app startup was raised which caused getting an instance of Sentry reporter via dependency injection library… you know the rest.

Solution, workarounds

I can’t think of any pattern that would protect the codebase from introducing such bugs, so sorry, no general solution here. If you are aware of such, please let know in the comments.

We did, however, introduce a safety mechanism - a middleware that checks whether the ContextVar has a value set, reports an error to Sentry if that’s true, resets the variable and proceeds with processing.

Request for patterns

As you can see, even though asynchronous programming concepts in Python are quite simple it’s possible to get into complex problems. If you know some other problematic cases, patterns for solving them or clever ways to refactor code to support async, please write in the comments. Same if you’re interested in some other topics related to async in Python.

It's not enough to implement features. In this post you'll find out what engineers should do to help business grow.

Discussing idea and gathering requirements

Clients should involve engineers in discussions when they have new feature ideas. It’s a stage when it’s easiest to introduce changes and avoid costly implementations.

Suggesting alternative solution

Quite often Clients will describe an idea for a solution to a problem they have. However, quite often, the idea is overly complicated.

Validating an idea is usually the role of a Business Analyst. But developers should still be critical of ideas. This is because they have knowledge of technical aspects that may make a suggested solution complicated.

When discussing the idea with clients, engineers and BAs should approach it with curiosity and critical thinking. This will help with uncovering the underlying problem that the feature is intended to solve.

Curiosity, from my experience, is not a problem in IT. It's what brings people here.

Critical thinking, or assertiveness, is something that is gained through experience. That’s why it’s senior developers' role to analyze an idea and say that the problem should be solved in another way.

Uncovering and discussing the core problem is a skill and, like any skill, can be learnt. Starting with asking open-ended questions is good, but if the problem or feature is more complex it’s not enough. Business Analysts and developers should be capable of leading the conversation with a client - structuring the discussion and asking the right questions. There’s a reason why conversations with domain experts are so important in Eric Evans’ “Domain Driven Design” book.

If you want to get skilled at discussing problems with clients, I encourage you to read a book by Michal Bartyzel “Conversation Patterns for Software Professionals” (or “Oprogramowanie szyte na miarę” if you know Polish; it’s a bit extended version of the English book).

Cutting on scope

What’s important to understand is that the client wants to validate the solution and get the major benefits ASAP. After leading the conversation with the client BA and engineers should easily realize what functionality subset will deliver the most benefits in the shortest time.

In my project we often implement the mobile-app facing features but delay or skip developing management of those in CMS. It’s the easiest division for us.

What can be challenging is communicating the scope cuts to the client. It's hard especially when the client insists on prioritizing non-core parts of a feature.

I need to confess that quite recently I failed at challenging the client. Because of that, my team spent a few weeks on changes that the client eventually acknowledged should have had a lower priority. What I missed was clearly showing the benefits the core functionality already delivered.

Implementation analysis and planning

After the client, BA and engineers agree on the scope it’s time for developers to choose the technical solutions and plan the implementation so that the costs and potential risks are minimized and benefits maximized.

Presenting limitations and solutions

Not long ago we were analyzing an upcoming feature which relied on integration with 3rd party services. We realized that quite big delays may be introduced by those external partners. They were caused by the nature of their services and the way they were used by users.

What I did was prepare a simple diagram that showed the impact of those limitations on the feature and users. That seems easy but I noticed that developers tend to use technical language when talking with clients. That makes discussions longer and results in clients misunderstanding the message.

Business oriented engineers also propose solutions to minimize their impact. That requires being aware of the goals of the feature to be implemented which brings us back to asking the right questions. Communicating different solutions can be challenging when solutions are quite technical. But in most cases it’s possible to show how different options impact:

• time to implement the feature,

• code maintainability (that includes scalability and resiliency),

• user experience.

Incremental implementation and gradual deployment

It’s the last stage so introducing changes is harder than in the previous ones. Yet, engineers can still use some techniques to maximize business benefits.

There are 2 general tools:

• planning gradual deployment,

• incremental implementation,

It’s important to note that the 1st one can make the 2nd much easier to plan and execute.

Gradual deployment

In the feature my team is working on right now we decided that it’d be good to release it to the users gradually. The advantages of such approach are:

• gathering initial feedback about the solution,

• have only part of the users impacted by potential bugs and,

• buy us some time to make our code properly scalable (what I like most).

A/B and canary releases are already quite popular which means there are tools that make it easier. Our project uses Firebase for deciding whether a user should see the new feature or not.

Incremental implementation

In Scrum the common way of working with big features is splitting them into smaller parts and implementing them one by one. That’s good for knowing the actual progress of the functionality development. Engineers should be able to find technical solutions for features to bring benefits ASAP.

This can be very challenging when the requested feature is totally different from all the other ones. Quite often this requires use of new frameworks, tools or architectural approaches. But it doesn’t need to delay bringing benefits of the new functionality.

Engineers should analyze whether the feature can be implemented in stages/incrementally. Initial stage should deliver working functionality that users can already take advantage of. This stage can compromise on resources usage efficiency, scalability or other factors depending on the functionality and technical solutions. While it’s already working the next stages can be developed and delivered.

What we lately developed in my team is fetching data from the external service via a periodic task. Implementing it that way has several drawbacks, such as wasting resources for sending requests that return no new data. But the big advantage is that we were able to deliver it fast. The next step is to create a new service which exposes a webhook for the external service to push data to. We decided to have it as a second stage of the implementation because this approach requires us to solve problems related to distributed programming and new kubernetes deployment setup, which we don’t have experience with.

As you can see, when planning the implementation engineers should take into account not only the technical solutions optimal for the feature but also their skillset and its impact on risks.

There are 2 main challenges with this approach:

• Developers need to make peace with the idea that playing with new, exciting solutions will be delayed,

• Clients need to reserve engineers’ capacity for the later stages of implementation. Abandoning subsequent phases delivery poses risks. That requires developers to properly communicate the hazards.

Communicate, communicate, communicate…

As you can see engineers have a big role in minimizing costs and maximizing benefits. It’s important for developers to have proper attitude and communication skills. That’s why I encourage you to develop yourself and your team in this area. Pay also attention to what you can improve in the business oriented approach.