Hey Friends,

thank you for still being part of The Blend ☕ I really appreciate you 🙏 .

Yes, it’s true, I was a shitty manager when I started. I’ve been introduced into the role at very early stage of my dev career (I was a frontend developer before - when there were no frameworks like Vue, React, and jQuery was a 🐐 … and to be honest it still is, and the most well know indie hacker (Pieter Levels known as levels.io) is still using it on all his sites

Pieter Leves post on x.com (https://x.com/levelsio/status/1755382814227235274)

But that’s not the case here. Let’s get back to the main topic. Like I said, I’ve been pushed to the managerial path very early. I was always good with people, I’m a good listener, thus I became a manager 🙈 .

Early years were very intense, and as a manager I’ve been listening to people’s problems, caring about them too much, to the point that they felt like my problems too… It was draining my mental capacity, I was really struggling…

Over the years I’ve been speaking with many people who are much smarter than me, were couple steps ahead of me in their careers. That was helping me a lot, to understand not to take everything personally. I’ve been listening to a countless number of podcasts about management, read newsletters and books… and what’s most important I’ve been practicing, putting all the things I’ve learnt into the process.

I don’t know how many 1on1 session I’ve had in my career - and actually I’d love to know the number 🙂 …. if I’d have to guess, I’d probably say, that over the last decade I’ve had over 1300+ 1on1 sessions (there were weeks with 10+ meetings).

Many of them were very challenging. Some ended up with letting people go, and some led to growth and promotions. It was great to speak to people that were aware of themselves, and their value. I’ve learnt A TON, and I’ve met some incredible people along the way.

After this time, I know that to be a really good manager you have to follow these 7 principles 👇️ 

My LinkedIn post

What I mean by that:

1. Asking questions has many level

Encourage open communication by asking insightful questions. This helps in understanding your team better and fostering a culture of transparency.

▪ Self-Reflection: Send a list of questions to your team member before feedback sessions to encourage self-reflection. This prepares them for the discussion and promotes personal growth.

▪ Peer feedback: Gather feedback from their peers to gain a well-rounded perspective on their performance. This can provide valuable insights that might not surface in direct conversations.

2. Listen more

Prioritize active listening to truly understand your team's needs and concerns.

▪ Manage silence: Embrace silence during conversations. It can be uncomfortable, but it often encourages more thoughtful responses and insights.

▪ Hide your EGO: Remember, you don't know everything. Be open to learning from your team, as they may have innovative ideas and perspectives.

3. Always give credit where credit is due

Recognize and celebrate your team's achievements to boost morale and motivation.

▪ Praise publicly: Acknowledge your team member’s efforts and successes publicly. This not only validates their hard work but also inspires others.

▪ Company-Wide recognition: Let the entire company know about significant contributions. This promotes a culture of appreciation and recognition.

4. Check-In with your team regularly

Maintain consistent communication, ideally on a weekly basis, to stay connected with your team.

▪ Avoid micromanaging: Use these check-ins to support and guide rather than control. This builds trust and autonomy within the team.

5. Don’t cancel or reschedule 1-on-1 meetings unnecessarily

These meetings are crucial for building relationships and demonstrating that you value your team members.

▪ Show importance: By keeping these meetings, you convey that your team members are important and their growth matters.

6. Always Assume Positive Intent

Approach situations with an open mind and a positive outlook. This mindset helps in reducing conflicts and misunderstandings, fostering a more harmonious work environment.

7. Don’t Be an Assh*le

Treat everyone with respect and kindness.

▪ Respect and Kindness: A respectful and kind approach builds a positive culture, encourages collaboration, and enhances team morale.

By following these principles, you'll foster a more productive and positive team environment.

Welcome to the Issue #13 of The Blend ☕!

In this issue, I’d like to say sorry—to you, and to myself as well—because I’ve let myself down by not sticking to my resolutions.

When I started this newsletter I told myself that this it - I enjoy writing, and as I’ve written in one of the issues “writing is thinking”. I am good at it, yet I stopped doing it.

For years now I’ve been fighting severe migraines, 2024 was a transforming year in that regards. I have found a great neurologist, and we are trialing different medications to make sure the headaches are gone. I am not yet in place where I can say they are gone, but I am definitely in a better spot at the moment.

In 2024 I’ve also changed my job and slightly pivoted in a different direction, as my role now is in Operations, not Technology. Yet I still think that everything that I’ve learnt still applies here as well. Do I miss working with engineering team, building a product? Yes, I do, I can’t lie. This role gives me much broader perspective on how companies are built, plus the venture building framework is super interesting.

I’d like to flip the cards on the unlucky #13

My topic for today is going to be feedback, BUT not how to give, what to say, or how to gather it… this time I’d like to focus on receiving one. Every manager is being taught how to use non violent communication, how to be more empathic etc. but we are never learning how to receive feedback from others.

We all know frameworks like “Sh*t sandwich”, we try our best to be empathic and make sure other side feels heard. But were you ever taught how to act when receiving one?

The bright side? Most folks are so bad at taking feedback that you just need to be slightly less awful to stand out!

The reason that most of the managers are burnet out is due to the fact, that they are afraid… of how the other person will react! It’s a huge pressure on mental health, and it in the end it creates unhealthy environment, when people are not entirely honest. According to Hardward Business Review (Link to the article) 2/3 of managers are terrified of giving their direct reports tough feedback because they're worried about the reaction they'll get 🤯…

Let that sink in… almost 2/3!

Alway assume positive intent

That’s actually one of my core rules at work. I always assume positive intent, no matter what. You can check out my Personal User Manual and see what are other rules worth applying - as my reader, you’ll get it for free, use coupon BETTERMANAGER100 to get 100% off. Personal user manual is a great way to share your values and work ethic with your team.

Let’s start with the fact that feedback is a gift 🎁 and always should be treated this way. Turn your defensiveness into curiosity. Try to understand what makes this person feel this way. Once they tell you, try to repeat in your own words to them, making sure you understood them correctly, and that you are on the same page.

Body language and atmosphere

To get honest feedback, look the part. Avoid raising eyebrows, looking shocked, or appearing upset—this shuts people down. Stay calm, sit up straight, and lean in slightly. Show you value and respect their input.

We're not focusing on how the other person could improve their feedback. Instead, focus on how you can encourage honesty. When receiving feedback, reward the person by creating psychological safety and making the conversation positive, so they look forward to it next time. This is how you build lasting connection, and encourage honesty in the team.

Until next time 👋 

Hi Friends,

last time we’ve unpacked why synchronous communication is important (and when). This time I would like to focus on, what I believe is harder to achieve, the asynchronous aspects of the remote work.

Asynchronous communication happens when two (or more) parties involved don’t have to be present, to have a valuable conversation, and cooperate towards common goal.

I have to admit, that in the beginning, I was not a fan of async communication. I’ve been working on-site for over a decade, and that creates habits and expectations. Like with everything in life - we should learn on our own mistakes. The first couple of months working remotely were hard, and as I described in my last newsletter - I’ve made the same mistake as a of people - I've tried to move the ‘offline’ work life to online. I’ve been doing meetings back to back, zero brakes, constantly available… exhausted all the time.

When I switched jobs in late 2020, I’ve started working with a fully remote team, spread across Europe - so we’ve had find a better way of working. In the early days, to build trust between team members, we were meeting daily, but as we’ve built up the trust, and everyone understood their way of working - we’ve moved to async communication most of the time.

What is async communication, you’d ask.

It’s the way of having a conversation, without being on a meeting, or chatting real-time. It’s about utilizing different channels of communication where people don’t have to be present at the same time. Out of which the most popular ones are sending email or direct messages over the app of your choice.

What I found works really well in the async communication is the utilization of the video form. It’s amazing how much more valuable a 1min video can be, instead of the long written message or a quick meeting… it let's the other side focus on the thing, in the time that suit them best.

As always - it’s about finding the balance, and use the best approach to reach your goals. Asynchronous communication is great, when you and your team highly value deep work and focus. It allows people to not need to be constantly online.

Every company can highly benefit from implementing the asynchronous communication into their workflow. It can help people achieve more, while doing less. Working this way, people can learn how to better formulate their ideas - as writing is thinking. Especially clear writing. Implementing video (eg. Loom) can help making sure everyone is on the same page.

Clear expectation, clear goals, clear communication, clear writing…

How to start with async communication? Whenever you want to create a meeting, ask yourself if it’s really necessary, or is there a better way to gather feedback you’re seeking for.

x.com/@WeAreWurkr

Asynchronous communication opens your company to a talent pool, that has been unavailable due to timezone differences before. If you can effectively communicate without real-time conversation, your colleagues / employees can be on the other side of the globe.

I also enhances collaboration on team work. People need to put more effort into the communication. On the other hand it allows the better work-life balance, and more flexible schedule to each of the team members. Emptier calendars mean, there is more time for deep focus, and uninterrupted work in the flow state.

All that glitters is not gold

While asynchronous communication gives more breathing space, less meetings, and more streamlined work… it’s not always like that, and it can’t be applied to everything.

Especially in the early days, you’re gonna see a lot of miscommunication or misunderstandings - and that’s ok! It’s about finding.

You should not apply asynchronous communication to things like 1-on-1 meetings, as these are meant to create a better relationship with your peer/manager

Asynchronous communication is a powerful tool for remote teams, enabling them to work more efficiently and effectively. By embracing async communication, you can unlock the full potential of your team and achieve more while doing less.

Remember, it's all about finding the right balance and using the best approach to reach your goals. Experiment with different channels and tools to find what works best for you and your team.

Thanks for joining me on this journey into the world of asynchronous communication! If you have any questions or comments, feel free to reach out.

Hi Friends,

/

Today I’d like to talk more about the communication in remote environment. I would like to divide it into two series - one about synchronous and the other will be asynchronous communication.
This week we’re going to focus on the former.

Remote work has been with us waaay before pandemic. It was just not that popular. Personally I’ve always loved the vibes from the office, but when I started working partially remotely around 2018, I never wanted to go back full time to the office. My commute was around 1h one way… The amount of time wasted in traffic + money on the gas - I don’t even want to count it.

Yes, I was able to listen to books and podcasts, but let’s be honest, when working remotely you can (and should!) go for a walk, and do the same, without spending a single penny (although I highly recommend going for a walk without headphones, to simply be present in the moment). Since 2020 I am working fully remotely, with occasional work from co-working space - to change the scenery and get some ‘focus club’ vibes.

Although I am a huge async fan and preacher, there is sometimes an urge to have a proper online meeting.

The Heart of synchronous communication

At its core, synchronous communication involves real-time interactions that allow for immediate feedback and collaboration. It’s the virtual equivalent of popping into someone’s office for a quick chat or brainstorming ideas on a whiteboard together. This immediacy is crucial for maintaining the flow of ideas, making swift decisions, and keeping the team spirit alive.

Sound great, right? Yes, BUT you can very easily kill the sense of it, and turn it into a nightmare. Meetings with no agenda, no pre-meeting prep, back to back calls without the time to reflect and jot down notes, crappy microphones or headphones, are just a few hurdles.

When jumping on the ‘remote work’ wagon you have to change the rules of the game when it comes to the online meetings. Set some ground rules. The number one rule should always be “we are not moving office behaviours to online”. Office culture is governed by its own rules.

Synchronous meetings can be really great when they follow these 5 rules:

1. Preparation is a key

   • share an agenda ahead of time, outlining topics to be discussed and objectives. Ensure all participants have access to necessary documents or resources BEFORE the meeting.

2. Set clear expectations

   • at the start, clarify the meeting’s goals and what needs to be accomplished. Assign roles if needed (e.g., note-taker, timekeeper) if you’re not using any AI assistant

3. Manage Time Wisely

   • allocate the appropriate amount of time and stick to the allocated time for each agenda item!

   • respects participants’ time, maintains energy levels, and ensures that discussions are concise and actionable

4. Encourage Engagement

   • ensure everyone has shown their perspective on the given topic, ask open-ended questions

5. Follow Up Promptly

   • summarize key decisions, action items, and next steps in a follow-up email. Include deadlines and assigned responsibilities

The Soul of synchronous communication

In one of my previous newsletters I’ve said that writing is thinking, but sometimes prioritizing a video call for complex discussion is crucial. This approach leverages the visual aspect of communication, which is often missing in text-based interactions, and it is easier to be on the same page (especially when talking about technical solutions). You can use collaboration tools like Miro or FigJam for a whiteboard brainstorming.

Complex topics often require a deep dive into details, brainstorming, and back-and-forth dialogue. Video calls can mimic the dynamics of an in-person meeting, making it easier to engage in these comprehensive discussions.

Video calls are also great and really important in creating a better relationship between manager and an employee. It’s much better to read and understand non-verbal signals.

The holy grail of remote communication

As with everything in life, it’s about finding a balance. Both synchronous and asynchronous communication have their pros and cons. Not everything requires an immediate response.

Encourage a mix of synchronous and asynchronous communication, allowing team members to work flexibly while staying connected.

In the next issue we’re gonna dive into asynchronous communication and you’ll be able to benefit from it.

Hi Friends,

🙌 First milestone achieved - 10th official Issue of ☕ The Blend is here!
Thank you for all the comments, questions and feedback. Means the world to me ♥️. Starting the newsletter for like-minded people was the best decision ever.

In this issue, I wanted to talk about different approaches one can take to tackle the technical debt

As an engineering leader, have you ever been struggling with a dilemma of new feature vs maintenance? You’re probably juggling on a daily basis multiple new business request with an long tail of tech debt.

As the engineering leader you know that tech debt has a very high interest rates and it can blow up in your face anytime. It can either bring down your product, or (what sometimes is much worse, especially in the smaller companies)… it can make people leave your company. Depending on your size, and the way you share knowledge across your organisation, this can be a very painful situation.

I wanted to talk about actionable tips and ideas you can take and put into motion, to start paying the tech debt.

There are 3 steps you can take:

1. Diagnosis

2. Guiding policies

3. Actions

🩺 Diagnosis - understand the situation, define status quo

In the beginning you need to firstly understand how big the tech debt is. There are multiple ways you can try to surface it.

1. Code reviews - in smaller organisation, you’re probably still quite close the code, and you can perform code reviews with your team. This will give you a hands-on information on what is the code’s quality being written .

2. Code analysis tools - there are a lot of different tools like SonarQube or Code Climate that have created the niche for themselves, so called Software Engineering Intelligence. They can provide metrics on code quality, potential bugs, and some sort of quantifiable measure of technical debt.

3. Test coverage - one of your metrics can be the analysis of your test coverage. Low coverage will indicate a higher technical debt, leading to potential bugs and maintenance issues. (You should be aiming between 60-80% of coverage)

4. Documentation review - one of the most underrated part of software product is it’s engineering documentation. Everything seems to be working great until either you have to onboard a new person, or someone just left the company, and you need to take over their part of work. Lack of documentation is almost never listed as part the technical debt, while it can create a huge problem. You should take that into account.

5. Number or bugs in backlog - this one is super important, especially the rate of how fast it’s growing. While you may have a lot of small issues, they can be experienced by a lot of customers, leading to a degrade of their experience. This metric should be tracked alongside of the incoming support requests.

6. Performance metrics - you should be monitoring the performance of your application, period. You should know your platform is struggling, before your clients have the opportunity to tell you that. You should be proactive here. If the performance is worse with each product iteration, you found yourself a new bomb to disarm.

7. Dependency monitoring - there are number of softwares (or services) that can help you monitor the outdated dependencies in the system, making sure you keep the tech stack at least up-to-LTS expiration. Ideally you should be running the newest stack whenever possible, but being realistic - it’s super hard. Your stack should at least have the actively supported by the creators, and getting security patches.

8. Refactoring impact - you should understand how often refactoring is needed. Frequent refactors can be a very good sign - if they are made alongside new features, meaning your team is paying off the tech debt, OR can indicate a massive tech debt. As a tech leader you should know which case is it.

9. Time taken for feature development - you should see how your teams reacts on new features. If they are hiding their faces in hands, and saying it’s gonna take ages… you should start digging. Your team might now much more about the issues that you’re not aware of.

10. 💡BONUS TIP: run the search on your codebase for a TODO comments… it’s really interesting what you’ll gonna find there. It can indicate the debt size taken, with each comment like that.

📄 Guiding policies

You should be fostering a culture of continuous learning, and encouraging team members to stay updated with current best practices and technologies. As you are a team, you should be collectively working on improving your processes, and guiding policies, can be a part of that.

Depending on the size of your organisation, the policies will be different, but here are couple of examples, so that you know what I mean:

1. No cloud policy - and by using the language from one of my previous newsletters, about building and influencing culture, you can set the policy:

2. No new languages - and using a similar approach as in the previous point, you could have a policy

Creating policies that will guide your organisation, are part of the “technology strategy”, and can directly impact the business decisions.

It is super important from many different angles:

1. It defines the business strategy and help Sales with speaking to customers, managing expectations

2. It created the dev culture that everyone agrees on, and don’t make unexpected architectural decisions

3. It is great to have such policies defined in your job description, when you’re looking for new engineers - setting these policies, will draw the attention of like-minded people, that will identify with the approach.

💪 Actions - how to approach tech debt

There is a great quote by Gene Kim, the author of the amazing book “The Phoenix Project” (highly recommend reading it!)

I could not agree more. If you leave the tech debt issue unresolved, you will start eating your own tail, and instead of creating business value for your customers, you will be working just to keep the light on - fixing one bug after another, putting out fire after fire.

For years now, I’ve been working with my teams to find the way to tackle these issues. Here’s what you can do 👇️ 

Apart from the quick insights from the list above like checking the codebase, doing the code reviews, and tracking the number of bugs, there are different, more strategic, ways of handling the tech debt.

As the engineering leader your probably asking about your “technical strategy”, and you might struggle with preparing one, BUT… the tech debt reduction is one of the key part of such plan.

Technical stakeholders

This is an easy scenario… if you are working with the technical C-level business stakeholders, they know how important it is to keep the up-to-date tech stack. Although it doesn’t mean, you’re immediately going to have a green light on paying it off - you should still have a proper tech strategy.

Non-technical stakeholders

This is how the most companies operate, and it requires a lot of effort to showcase the problem, and get the business approval. The first step is to always get your teams’ perspective on the tech debt and try to workshop possible ideas with them.

I want to stress one important thing → the strategy is not to make everyone happy, but to focus limited capabilities and capacity to solve the problem we pursue.
Not everyone in your team will like all the policies and new approach, but they all have to agree to abide by them.

I always loved the meetings we’ve had with my team, called “Teamspective”. It was NOT a meeting about the retrospective on our last cycle of work, but a more strategic discussion. We were discussing metrics and processes we can optimize - striving for excellence.
Being transparent about the metrics I’ve talked about in one of my previous episodes is key (read the issue about the metrics). Really small changes can lead to huge gains.

PR template

As simple change as introducing a PR template with a small checklist can be very beneficial, and sets the standard. You can start with this simple checklist:

# Description
My PR changes/introduces/creates/deletes...

# Checklist:

1. I have manually tested my code before handing it over
2. I have written test to my code
3. I have performed a self-review of my code
4. I have added Linear issue ID to the PR name
5. I have made corresponding changes to the documentation

Super simple, yet so powerful. Seeing such checklist in every single PR, makes people accountable for their work, and they feel more obligated in following the rules, even if it’s a small change.

Code Review process

Check how long usually it takes to Code Review the PR. We’ve seen that sometimes PR’s were sitting, waiting for CR, longer that they’ve actually took to write 🤯 … introducing a policy as simple as “Start your day with Code Review” almost doubled the amount of work delivered (we’ve been working in weekly cycles, ended with a release).

Both Code Review marginal gains, are gatekeepers to the quality, thus tech debt reduction.

Understand the time investment balance

This is a big one, and it requires business understanding. Your business likely has a seasonality in sales and usage. You can prepare a year-round plan for the business stakeholders, based on the data from previous years.

Time investment balance

Using historical data, you can plan ahead more time consuming changes and infrastructure updates, knowing when the business is slower, or there is a lesser usage of your platform.

Prepare a plan

Now you know seasonality of your business, and you know which area needs to be fixed/refactored/removed so that you can start paying off the technical debt. It’s time to prepare a plan.

You can’t tackle everything at once, so the best way is to create couple of iterations throughout a year. This is the way I’ve approached it:

1. Twice a year (between Q1/Q2 and Q3/Q4) - 🐛🔫 Bug Hunting. Depending on the size of your organisation, either you’re going to do it yourself or with your Product counter part. You prioritize smaller issues, more of a quick wins, that will make your product better, but there is never a good time to do them, because there is always something more important.
   I would aim to spend 2 weeks (1 cycle of work in my case), as this is the timeframe that you can already ship a lot of meaningful work.

2. Vacation time - In my experience July/August was the time where there was much less people using our platform. This time we were working on improving the broader UX, making our product more usable and eye pleasing. The cognitive friction for users is smaller after some time off.

3. Christmas time - ideally, this is the time when you can work on the biggest changes to the backbone of your stack or infrastructure. This is usually the slowest period, and you can work on the biggest. For that period I’ve planned things like upgrade or Ruby and Rails versions to the newest ones, making sure we’re bulletproof for a year ahead.

Maybe you are a B2B SaaS that want to go through ISO certification to be a better choice for enterprise customers. You have to be aware of that, so that your plan can account for that.

Maybe you will have to run yearly penetration tests with 3rd party companies (that’s also a very important part of the engineering budget).

Maybe there are new laws that will affect your business - like GDPR, or your enterprise customers will require that the data cannot go outside of EU.

As engineering leader you should be on top of all that, making sure it’s planned ahead.

Hi Friends,

In this issue I would like to tackle the topic of why work is never “just work”. I’ve lately came across a great Linkedin post that was touching the area of estimation.

Before diving in, I think it’s worth starting with a great quote by Tom Cargill

Which is true, and catches the perspective of almost every single IT project. People suck at estimation, especially when it comes to problem solving, period. Every single project is either underestimated, or highly overestimated. And it’s almost impossible to estimate precisely.

I’ve touched on the metrics in my previous newsletters, and I’ve mentioned there that if we’re gonna measure development success eg. based on estimations - people will simply double/triple them. Meaning they’ve already are crippled.

Why estimations are hard?

The simple answer is - because you’re unable to predict the future.

But there is a multitude of other smaller or bigger factors that will influence it. Let’s break down couple of them 🤔

1. You’ve never done it before - maybe you’ve done something similar, but probably never exactly the same.

2. People can change - you’re working on the team, and one of the members resign, or there is a new comer that you have to onboard - both scenarios will impact the estimations and delivery date.

3. “Apples to Apples” - an estimation will be different to people with different skillset. A task can be done in 1 day by a senior developer, but will require more time for a junior developer.

4. You’re a weak link a chain - We’re not robots, we tend to guess wrong, forget about something etc.

Estimating is a skill - you can get better at it. You can gain more experience with each finished project. But that not necessarily mean you’ll be 100% accurate.

What are the components of ‘the work’

I’ve found a great graph, that was created by Dave Stewart 

Dave Stewart

It roughly shows how much moving parts there are, beside the ‘actual work’, and they all influence the overall estimation, Dave broke it into 8 categories:

1️⃣ The work around the work — meetings, reviews, project management
2️⃣ The work to get the work — research, experimentation, scoping, quoting, pitching
3️⃣ The work before the work — configuration, setup, services, infrastructure
4️⃣ The work — the actual build, design, and testing of the product
5️⃣ The work between the work — iteration, debugging, refactoring, maintenance, tooling
6️⃣ The work beyond the work — changes, omissions, nice-to-haves, scope creep
7️⃣ The work outside the work — surprises, contingency, disasters, mission creep
8️⃣ The work after the work — hosting, deployment, security, support, updates, fixes

In one of my project, we were working on the Google Chrome Extension, and I felt really comfortable that I can deliver an MVP within 6 weeks timeframe. We’ve created the scope, the developer started the work… and yes, within 6 weeks we’ve had a working solution, it wasn’t perfect, but it was working. The final product though, which was delivered to the clients - took us about 2-3 more months. Just when I thought I am at 99% done, I’ve actually been around half way 😉. Yes, this means that the scope must have been crippled, but actually the itteration proved, that we didn’t know everything when we’ve started working on it. Another issue was QA on different environments, hardwars produced a lot of bugs, we’ve had to cover etc. etc…

There is so many components, that it’s impossible to take them all into account.

How to tackle this issue?

There are couple of approaches one can take to make estimations more precise, OR to stop using them in favour of something else.

You can estimate in days, in points (most common way is to use Fibonacci sequence), quarters (by giving a very rough ballpark estimation).

You can also reverse the approach and instead of estimates, start using appetite. This approach was introduced by 37signals in their book called Shape Up. Showing their unique way of building software.

No matter which path you’re going to follow, the most important part of each project is to break the pieces down to the smallest task possible. If the task is small, it’s easier to estimate it precisely.

There are more benefits to that approach. I’ve mentioned it in the topic about engineering metrics - the smaller the PR is, the easier is to merge it (faster code review, less conflicts, easier to understand).

I wish a good luck with your future estimations, and hopefully this articles shed some light on this vague topic.

Welcome to the Issue #8 of The Blend ☕!

In this issue, we are continuing the journey into the metrics. In a previous newsletter I’ve shared how can we divide metrics into 3 different groups (crawl, walk, run). This time I am going to share what metrics I am tracking, why and how can you influence them to the benefit of your team.

We are going to tackle the most important ones, giving you the best overview of what is going on in your team. Let’s start with the WHY, and understand what are measuring for in the first place. Engineering metrics help us:

1. Track the performance over time. It gives you the ability to spot trends, making more data driven decisions. (Examples below)

2. Identify bottlenecks. By measuring various aspects of the SDLC, teams can pinpoit where bottlenecks are occurring, whether in coding, reviewing, testing or deploying.

3. Improve productivity. Metrics can highlight areas where processes need improvements or be streamlined. Ultimately enhancing productivity of the whole team.

4. Predictability. By analysing historical data, teams can make more accurate predictions about project timelines.

5. Continuous improvement. Regular measurement and review of metrics enable teams to engage, iteratively refining their processes.

6. Alignement with business goals. Metrics help ensure that engineering efforts are aligned with the broader goals of the organisation. They can demonstrate how technical work contributes to the business objectives.

Engineering metrics

Now as know why engineering metrics are important, let’s dive into the metrics themselves. I’ll start with the metrics that in my opinion is one the most important ones:

Cycle Time

CYCLE TIME - represents the average time Pull Requests have spent across the ‘in progress’, ‘in review’, and ‘ready to merge’ stages before being merged. It’s the amount of time from when work starts on an item (like a feature or a bug), until it is delivered. It indicates the efficiency and speed of your development process. It helps you identify bottlenecks and highlights the team’s ability to deliver.

Pull Request in progress

PULL REQUEST IN PROGRESS - represent the number of pull requests that are currently open and being worked on. It helps in understanding the workload of the team and the distribution of tasks. (Too many open pull requests can indicate bottlenecks in code review or testing)

Total Throughput

TOTAL THROUGHPUT - Measures the number of items completed in a given time frame (The total number of merged PRs). This metrics is crucial for comprehending team’s productivity and can assist in planning capacity and making future projections.

Time to first review

TIME TO FIRST REVIEW - This measures the time it takes for the first review to happen on a pull request after it was requested. It’s an important indicator of how quickly the team responds to new work and can highlight issues in the review process.

Merge time

MERGE TIME - Tracks the duration from when a PR is approved to when it is actually merged into the main branch. Shorter merge times can indicate a more efficient code review process and a healthy flow of work. Depending on the workflow, it can also indicate how long the ticket is going through a QA process, as it passed the Code Review, but is still being tested separately form the main branch.

Investment balance

Investment of time balance. This metric looks at the balance of time invested in different activities (new feature development, technical debt reduction, bug fixing, etc.). It’s crucial for strategic planning, ensuring that the team's efforts align with the company's goals and priorities. This metric is super interesting, as when looked at from a really high perspective (a year) it can show things like (based on the example above):

• the team tends to work more on bugs in the summer months, where application usage is slower due to holidays

• most of the work on the new features in happening in the last 2 months of the year, yet again, due to slower period, making sure there is a lot to shout about in the new year from the marketing perspective.

This quote is commonly attributed to Peter Drucker. It emphasises the importance of measuring performance in order to identify areas for improvement and drive progress. For even more in-depth understanding of how your team performs, you should combine code-related metrics with people-related metrics.

eNPS in Officevibe

As we all know, engineering teams are creating value collectively. Yet to understand the full picture you also need to work on individual metrics. The most basic and important one is eNPS (Employee Net Promoter Score). eNPS provides a numeric value that represents the overall employee satisfaction within an organization.

Key metrics for employment engagement

There is MUCH MORE you can learn about your team, and understand the whole picture. It can help you with:

1. Understanding Employee needs. Metrics like 'Personal Growth', 'Recognition', 'Relationship with Peers', and 'Happiness' provide insights into what employees value in their workplace. Knowing this helps manager create a better work environment that supports the personal and professional development.

2. Improving retention. Factors such as 'Satisfaction', 'Alignment', and 'Ambassadorship' are linked to employee retention. By tracking these, a company can take proactive steps to improve employee loyalty and reduce turnover.

3. Enhancing productivity. Engaged employees are typically more productive. Metrics like 'Wellness' and 'Relationship with Manager' can signal areas where improvements could lead to higher productivity levels.

4. Identifying problems early. A low score in any area, such as 'Relationship with Manager', can serve as an early warning system for deeper issues that could affect employee morale and productivity if not addressed.

5. Aligning with Company Goals: 'Alignment' measures how well employees' personal goals match the company's direction. High alignment can enhance team cohesion and drive towards common objectives.

We’ve learned know ‘WHY’, now let me tell you ‘HOW’

This part of the newsletter will be quite short, as I want to give you low hanging fruits. There are tons of products that can help you achieve all that, and understand the metrics. I’ve been using many of them, but there are 2 that stole my heart:

1. Swarmia - this tool integrates with you Github repository, and your project management tool ( I use Linear - you can learn why 👉🏻 here ), and Slack. It is super easy to install, and get ton of value straight out-of-the-box. It scans your repository, and based on each activity it gives you a historical overview.

2. Officevibe - it’s a tool that helps leaders like myself, understand the engagement and performance of each team member. I’ve been using 15five.com before, but Officevibe stole my heart, and gave me much more value and better integration.

Make them stick

Working agreements in Swarmia

I’ve written an Linkedin article, explaining why Working Agreements are great ( You can read it 👉🏻 here ). After you get your first metrics about the team, the next step is to optimize them, and keep the continuous improvement mindset.

Swarmia has a built in feature to track the defined rules. Working agreements are meant to be 'habits’ for your team, and like all habits, you need to make them easy to follow ( Swarmia has them predefined, so you don’t have to think about it ). They need to reflect what type of team you are. Saying out load that “We are the team that…” builds the identity and culture.

These are working agreements that helped me and my team to deliver more and keep the continuous improvements:

1. We are the team that… merges PR’s in less then 7 days

2. We are the team that… avoids pushing directly to main branch

3. We are the team that… limits the in progress to max 10 PR’s

4. We are the team that… links all PR’s to issues

5. We are the team that… reviews PR’s in less than 2 days

This approach creates the environment of accountability, and helps optimizing the metrics.

How to stay on top of everything?

What is best, is the fact the Swarmia integrates seamlessly into your workflow. Each day you’ll se a daily digest of all the things that are important - how many PR’s are waiting to be reviewed, how many is in progress, and it will show it agains the defined working agreements.

🏁 Stay curious

That will be all, when it comes to basic and fundamental metrics of engineering teams. Please remember about the wise words from Charles Goodhart:

👋🏻 Hi Friends,

and welcome in the Issue #7 of ☕ The Blend. This time I would like to discuss the measurement of remote engineering teams.

As you know (or not), engineering teams are hard to measure. Software engineering involves writing code, which is inherently logical and measurable. Engineers often work with exact specifications, and defined goals. They are creating solutions based on measurable criteria. Yet, when it comes to assessing the performance of individual engineers, the metrics are not always as clear.

The irony in measuring lies in the contrast between the precise and quantifiable nature of their work and the challenges in applying similar precision to evaluate their performance.

WHAT should you measure?

Unlike salespeople, whose individual contributions can be measured (like number of customer calls, number of leads acquired, revenue generated etc.). Value created by engineers is much more complex. Most of the times (unless you're a one man army) it is driven by a collective effort, synergy and is interdependent.

You can't measure amount of code produced, as sometimes much more value can be delivered when the code is deleted.

Having said that, there are couple of things you can measure, that will help you navigate through the unknown.

There are 3 groups of metrics:

• CRAWL metrics

• WALK metrics

• RUN metrics

🧟‍♂️ CRAWL metrics

At the 'CRAWL' stage, metrics are basic and foundational. They focus on establishing 'minimal viable processes' and are ensuring stability. In software development, this might be DORA metrics, or in product world the MAU (Monthly Active Users) metric. The goal is to get things started and establish a baseline from which to grow.

What is DORA metrics?

DORA metrics serve as a guide to how well the engineering teams are performing and how successful a company is at delivering software.

They include:

1. Deployment frequency - how often an organisation successfully releases to production

2. Lead Time for Change - the amount of time it takes a commit to get into production

3. Change Failure Rate - the percentage of deployments leading to a degradation in service that must be addressed.

4. Time to Restore Service - how long it takes an organisation to recover from a failure in production.

🚶🏻‍♂️WALK metrics

In the 'WALK' stage, the focus shifts to optimisation and efficiency. Metrics become more sophisticated and are used to refine processes. In engineering it can be Cloud Costs, or performance against SLA. In product, it can be NPS Score, or level of integration of data sources. The idea is to build on the basic capabilities established in the CRAWL stage and start optimising processes.

🏃🏻‍♂️ RUN metrics

At the 'RUN' stage, the organization is focusing on advanced and strategic goals. Metrics at this stage are about driving innovation and leveraging processes for competitive advantage. In engineering, this could mean Team Satisfaction (eNPS), Team Health or Number of Vulnerabilities. In product, it could involve Flow Time, ROI, or Flow Velocity. The goal is to operate at a high level of efficiency and innovation.

HOW should you measure?

There are numbers of way you can measure the above. Currently there are tons of software on the market that helps with that. 

I will be digging deeper in the upcoming releases on what tools I use, and how I assess the metrics, so make sure to subscribe and don’t miss it.

WHY should you measure?

There are numbers of argument that are in favour to do it. Starting with consciousness of your teams' work, through understanding what impacts their flow.

• DORA metrics help in understanding how quickly and efficiently the team can deliver new features and fixes. This understanding helps in streamlining processes, removing bottlenecks, and improving team productivity.

• You will boost the quality of the product you're building.

• Regularly measuring and reflecting on these metrics encourages a culture of continuous improvement. Teams can set goals and track progress over time, fostering a mindset of always seeking to do better.

• By improving deployment frequency and reducing time to restore service, the organization can respond more quickly to customer needs and market changes. This agility can lead to higher customer satisfaction and a better user experience.

• These metrics help align the engineering team’s efforts with broader business goals.

• Faster, more reliable deliveries and improved quality can contribute to the success of the business.

With that you can set the baseline and then optimize. You don't always have to hire another person to your team to get more work done. In fact, hiring has quite the opposite effect when you don't measure the efficiency.

The Goodhart's Law

While metrics are invaluable for understanding and improving the engineering processes, it's crucial to have in mind the Goodhart's Law: 'When a measure becomes a target, it ceases to be a good measure'. It reminds us that over-relying on specific metrics can lead to unintended consequences. When we focus too narrowly on metrics as targets, teams might be incentivised to game the system, optimising for the metric rather than the underlying goal of quality and efficiency. For instance, if we overly emphasise deployment frequency, we might encourage more frequent but less meaningful releases. It's essential, to balance the reliance on metrics with an understanding of their limitations and to continually reassess their relevance and impact on our true objectives. Metrics should guide and inform, but not dictate, our strategies and actions.

🏁 In the next episode...

It's clear that measuring the work of software engineering teams is both an art and a science. The journey from CRAWL to RUN metrics isn't just about numbers - it's about understanding the story they tell about our teams, our processes, and the value we deliver. It's about making informed decisions, driving continuous improvement, and ultimately, creating better software.

In the upcoming issue I'll be diving more into what (and how) I measure my team, and how can you impact these metrics (real life examples).

We'll also explore the human element of Engineering Management. Behind every metric, there's a team of talented individuals striving to make a difference.

Welcome to the Issue #6 of The Blend ☕!

In this issue, you will read about the learnings I’ve discovered while using Linear as the project management tool.

Introduction

For years I’ve been using Jira when working with bigger projects or bigger development teams. Jira was a go-to platform for almost everyone I knew who was managing more complex projects.

A little disclaimer… I am a perfectionist when it comes to the work organisation, as well as desk organisation - I always have to have my virtual and real desk clean, and I even have a huge pet peeve when my Downloads folder gets a little messy 😬… anyone who has seen Jira or worked with it, knows, it’s really easy to turn it into a big pile of 💩 when you don’t keep it in boundaries (especially when it comes to status, and workflows).

The transition

When I’ve joined Hinterview in 2020 they’ve been using a piece of software called Hygger which was a Kanban board very similar to Trello, but on ‘steroids’. Mostly it was doing the thing it was meant to be doing, but was very frustrating for me as a manager - hard to easily report on the work, and impossible to manage the backlog with 🤦🏻‍♂️… As I already had a couple of years of experience using Jira, it was a natural way of evolution for me.

I’ve set up everything on a side, migrated all tickets from Hygger to Jira, kept Hygger for couple of more months to make sure I didn’t miss anything important.

There it was… a clean, fresh, setup the way I like, quite easily (and most of the time painfree) adopted by the team… I as please with the change, we’ve onboarded different teams as well (OPS and CS), started using Confluence as the internal knowledge base and product documentation… I was improving the workflows, introducing automations, to cut down on the friction even more, trying to make life easier for me and developers.

Everything was almost perfect… there was one big PAIN I’ve had… over the years Jira became this behemoth app, with TONS of views, customizations… but it also got really slooooooooow 🦥… I think they’ve tried to become this one-size-fits-all app.

The reality started to look very different…

Reddit /r/ProgrammerHumor @AaronNBrock

Being part of couple of different communities and Slack groups, I’ve been exposed to different perspectives, tools and opinions. This where I’ve heard this name for the first time Linear… as I love exploring new apps, methods, tools, I’ve jumped right in to test.

It took around 5min and I immediately knew this is going to be a game changer when it comes to project management. Easy Jira import, couple of clicks, desktop application (by far the most important thing)… I was instantly sold ❤️

I remember the day, I’ve sent this message to the team👇🏻

Slack message that I’ve sent to the team in Feb 2022

Since then all pain related to project management where gone . Linear is the tool is created by people who built amazing things in the past (Airbnb, Coinbase), and know what “great looks like”.

🎨 Design - it’s beautiful

I know, design is a very subjective thing, one can love what other hates. For me personally, the design of the application is crucial and I simply like to work with the software that is aesthetic. The level of details they are thinking about, is contained in this one tweet:

x.com - Karri Saarinen, CEO of Linear

Design and development craft in that product is on a TOP level.

@Linearapp - right after the initial setup

⚡ Speed - it’s insanely fast

If you’ve ever worked with Jira you probably now the pain of endlessly loading screen when you want to jump from page to another. This is not the case when it comes to Linear.

The time you’re getting back is worth the hassle of migration (which by the way is super easy, with just couple of clicks).

This is a real life example of me clicking - no speed up! It’s crazy!

⚙️ Workflow - super easy to use and ties into your current tech stack

For me, customizability of Linear vs Jira is similar in my opinion to iOS vs Android.

If you don’t want to adjust it to your very specific needs, it works great straight out-of-the-box, but if you want to dig in, you’re more than welcome to.

It’s integrated with dozens of apps, and I’d be really surprised if you’ll be able to find even one app, from your tools stack, that it is not connected with.

Personally I am using the integration with:

1. Github

2. Slack

3. Swarmia

4. Raycast

5. Figma

What I really appreciate about Linear is that they also want to impact how software is being developed. They have a set of principles and practices they strive for (you check them out here). What resonates with me is their way for doing cycles, following their docs:

Changing the perception of a “sprint” 🏃🏻‍♂️ to a cycle ♻️ and creating a momentum, feels more natural and is better for your mental health - as you no longer have to constantly run (sprint) towards the goal, but instead you create a momentum and a healthy routine of work cycles.

📊 Reporting - easy as 1, 2, 3…

One of the superpowers that Linear gives you, is the ability to filter EVERYTHING and access your data from every possible angle. You can then create separate views and assign them to a sidebar (by assigning them to favourites ⭐). Combining all that filtering power with the performance of the app - makes it a pleasure to work with.

The ability to filter across EVERYTHING

You even have the ability to create Roadmaps inside of it:

Roadmap view in @Linearapp

From the project delivery point of view, Linear is giving me insight, no other tool has ever given me.

⏲️ Productivity - keyboard shortcuts and much more

Everything I’ve described above is just a tip of the mountain but Linear let’s you easily be “1% better each day”, and the team is going to love it 🙂.

What is super cool, especially for people like me, who love productivity and optimizations, is the fact that Linear is created with keyboard-only usage in mind. Everything has it’s own keyboard shortcut, and that approach let’s you FLY 🚀 through the work.

🏁 Closing speech

Let me say one thing out loud - tools are just tools, and they won’t do the job for you. While for me Linear was a total game changer, and made my job 100x faster, it does not mean it will do the same for you and your workflow. I wanted to show you, that in a particular environment, it might give you a lot. Nonetheless I still highly encourage you to try it for yourself - as I strongly believe you may gain a lot.

If you’d like to know more, let me know, ping me with questions - I’d be more than happy to share my knowledge.

I hope I’ve earned the privilege of your time,

Marcin

Welcome to the Issue #5 of The Blend ☕!

In this issue we are going to talk about productivity tips for tech managers. I am currently a Head of Engineering. Productivity is crucial in my work, as on a daily basis I am bombarded with different notification.

There is a very powerful sentence:

So there are 2 choices… you can either make this quote become your reality (and drive you towards burnout) OR grab a bull by the horns and be the master of your time.

Throughout my career, I’ve let others schedule meetings directly on my calendar, and somehow always end up frustrated by the choice they’ve made - even though I personally let them do that! (I know how it sounds 🤦🏻‍♂️). I could have only be angry with myself that I’ve let that happen.

A lot of those meetings could have ended up being a short email. 

This was pre-covid, working on-site at the office. All those meetings were giving the sense of “doing a ton of work” - as it turned out very false sense.

When covid hit and everybody started working remotely, I knew something has to change. In the beginning every company was simply tried to replicate the communication scheme from on-site to on-line, having multiple meetings throughout the day, one right after another - which from the point of time management was more efficient, as you didn’t have to walk to a different meeting room, you’ve just clicked to a different zoom/google meet link…

This approach brought even more burnout among people in tech, and it even got it’s own name “zoom fatigue”:

Couple of months in to the covid, I’ve made the decision to change jobs. The company reached out to me for a remote Engineering Management role for their engineering team spread across Europe. Couple of interview steps, conversation with CEO, CTO… immediately one things stood out clearly for me “async communication”… 3,5 years I am in the place where online meetings are very rare, zoom fatigue does not exist, and yet we are able to communicate effectively.

There are couple of principles you have to follow in order for this to succeed:

Learn how to express your thoughts in written form

Async communication in most cases is based on written form. You and your team needs to learn how to clearly express their thoughts on ‘paper’ (keyboard 😉). This skill is essential, especially when working in the international team, where communication is not in your mother tongue.

Don’t start with just “hi 👋🏻”

I know it may sound counter intuitive, but hear me out 😉 . When working remotely, don’t just say “hi” and expect an answer. The whole point of async communication is that the other side of the communication chain can read and reply in their own time, don’t expect immediate answer.

I have to beat my chest on this one, I am still sometimes making this mistake 🙈

You should think about this communication similar to email. Write the whole message, and send it at once, so that person on the other side can reply to your need, but on their own terms. This way actually speeds up communication, not the other way around.

Don’t expect immediate answer

As I’ve mentioned in the point above, the key indicator for async communication is when a people can communicate on their own terms, in their own time.

You should not expect immediate reply, nor send one if you don’t feel like to. Of course everything depends on the priority of the issue, and when the platform is down - you might want to have more async communication - but this type should be agreed beforehand and have a separate process.

Implement video

When written form works fine in your team, you can level up your game by implementing video into the workflow. You’ve found a bug that you want to highlight, or you’ve developed the feature you’re trying to show, or maybe you have to give a feedback to the design… record a video, and send it through.

Nowdays you have a range of different tools that you can use to achieve that - Slack has this feature build in, Loom has it’s free tier that will be more than sufficient for you.

Record screen and camera preview highlighting what you want to express

Question the invite - master the meeting

This is a two way street… there are couple of good habits when it comes to the meeting to make sure it’s going to a productive one.

1. Clear agenda and objectives: before the meeting, circulate a clear agenda among the participants. This should outline the meeting's purpose, topics to be discussed, and any preparation required. Having specific objectives for what the meeting should achieve helps keep the discussion focused and productive.

2. Time management: respect the scheduled start and end times. Starting on time honors those who arrive punctually and ensures that the meeting doesn't overrun, which can disrupt participants' other commitments.

3. Engage all participants: encourage active participation from all attendees. This can be done by asking direct questions, soliciting feedback, or having different team members lead various parts of the meeting.

4. Follow-up and action items: end the meeting with a summary of decisions made and action items assigned, including clear deadlines and responsible parties. After the meeting, send these points out in a follow-up email or message.

Always promote the practice of these effective habits, and be sure to adhere to them yourself when you are hosting a meeting.

Are meetings bad?

Not at all! Asynchronus communication does not mean - NO MEEETINGS. This approach just emphasize the need of the balance.

We are people, and having a sense of belonging is one of the most important things for us. This can only be built by direct communication with others.

There is plenty of space for synchronous communication in the asynchronous world. As a tech manager you must conduct your 1-on-1’s with the team, and they should definitely be in person meetings.

That’s all folks…

Next time I will show you what tool stack I use in my everyday managerial work to boost my productivity working remotely.

I would love hear your productivity tips or challenges you have when working remotely with your teams.

Resource roundup

A collection of links exclusively for subscribers:

1. MeetingBar - meetings at your finger tips, app that let’s you instantly joing meeings from different providers (zoom, google meet, teams).

2. AI Profile Picture Maker - create profesional profile picture in seconds with AI.

3. Arc Search - Fined everything, but faster… the mobile browser that browse for you, clears the clutter, and gets you where you want to!

I hope I’ve earned the privilege of your time,

Marcin

Welcome to the Issue #4 of The Blend ☕!

In this issue, the productivity meets technology.

I would like to show you more in depth how my workspace is designed and which software (and why) I am using.

In the realm of work and productivity, the marriage of technology and efficiency is not just a convenience; it's a game-changer. As an Apple fanboy and an advocate of aesthetic computer setups, my journey into the world of remote work marked the beginning of an era – an era where the perfect blend of software and hardware became not just a desire, but a necessity. This blend, for me, is where functionality meets joy; it's about using tools that don't just get the job done but make me happy to use them.

Hardware

When it comes to hardware, every piece of my setup is carefully chosen for both its performance and design aesthetics. My main gear includes a Macbook 14” M1 Pro, a Xiaomi Mi Curved Gaming 34” monitor. I’ve found this monitor to be a perfect balance between size and screen real estate. I prefer one bigger screen instead of 2 smaller ones.

The keyboard and mouse of my choice are NuPhy Air75 and Logitech MX Master 3. NuPhy Air75 is a low profile mechanical keyboard and with wisteria switches that are perfect harmony between noise (clickity-clack) and the key travel - is fast and quiet. While Logitech MX Master 3 is designed for comfort and ergonomics. Its shape is crafted to fit naturally in the hand, reducing strain during extended use. This makes it ideal for users who spend long hours working on a computer.

As I am working remotely I care about the quality of my video and audio. I think it is important, as if the quality is high, it lessen the cognitive strain. That’s why I use a quality microphone Blue Yeti Nano on a boomarm with a shock mount to reduce the possible noises.

I also use monitor light bar by Xiaomi, that decrease eye strain. Unlike traditional desk lamps, a monitor light bar attaches directly to the top of the monitor, saving valuable desk space. This is particularly beneficial for compact workspaces. It has a remote that gives you the ability to change the brightness and the colour temperature.

Software

The synergy between my hardware and software choices is what truly brings my productivity to life. Whether it's the smooth integration of my Apple devices for seamless work transitions or the way Make.com automates complex tasks, every element of my setup works in harmony. This integration is not just about convenience; it’s about creating an ecosystem where each element complements the other, resulting in an optimized and enjoyable work experience.

There is couple of essentials that I can’t image work without:

1. Arc Browser - this is by far, the most important part. The Browser Company did an incredible job to optimize how people can benefit from using this browser. It’s a Chromium-based browser, that has A LOT of cool features. Highly recommend everyone to use it.

2. Raycast - it’s a supercharged application launcher for macOS, that has a TON of amazing features like snippets, quicklinks to begin with. With a simple command I am able to

3. Cursor.sh - an AI-first code editor, that let’s you use your own OpenAI key to enable the conversation with your code

4. Warp - my go-to terminal application, that is fast, beautiful, has AI built it and things like workflows (where you can save a set of your commands, that can be triggered with one command later).

5. Notion - my second brain, I use it to keep all the important information, track and measure my goals and projects.

6. Notion Calendar - it’s my calendar app of choice, I was using RiseCalendar before, but a rebranded Notion Calendar (former Cron) stole my heart again

7. SetApp - it’s a subscription based marketplace of tools (that is constantly growing). For a one subscription you get tens of applications, the best ones I use are:

   1. CleanShotX Pro - the best screenshot grabbing application ever, with annotations, cloud sharing etc.

   2. Spark Mail - superb email client, that utilizes keyboard shortcut for more productive workflow.

   3. CleanMyMac - an app that scans your computer form unnecessary (or danger) files, processes etc.

   4. Bartender - for organising my menu bar

8. Linear - being Head of Engineering, I am managing projects, and after using Linear, I never wanna look at anything else. The most superior Project Management tool I ever worked with.

9. Endel.io - Endel uses algorithms to generate soundscapes that adapt in real-time to various personal inputs like time of day, weather, heart rate, and location. The sound are created based on scientific studies and principles. They utilize aspects of sound psychology and neuroscience to influence mood and cognitive function.

Reflecting on my journey, the biggest lesson I've learned is that the right tools can significantly enhance your work experience, but they must be accompanied by the right mindset and environment. My advice to those looking to optimize their workspace is to start with understanding what brings you joy and efficiency. Experiment with different setups and find your unique blend that resonates with both your professional needs and personal style.

Finding the perfect blend of technology and productivity is a journey of trial and error, but it's a journey worth taking. It's about creating a space where work doesn't feel like a chore, but a seamless and enjoyable part of your life. As you embark on this journey, remember, the right blend is out there, waiting to be discovered.

Resource roundup

A collection of links to stuff I think are worth sharing.

• [Productivity] Raycast 101 - enter the world of Raycast with Pedro Duarte to see where you can gain superpowers.

• [Engineering] Top 100 Developer tools of 2023 - selfexplanatory title 🙂 

• [AI] AI + kids = creativity - the fun little story of how AI sparked curiosity in my daughter.

I hope I’ve earned the privilege of your time,

Marcin

☕

☕ Hi and welcome to the Issue #3 of The Blend ☕!

This quote is so powerful, it’s the essence of procrastination in my opinion. We are the biggest threat to our own achievements.

At the beginning of my journey with self-development, I’ve discovered that there is no such thing as motivation. You don’t need that magic ‘motivation’ to do stuff… actually it’s quite the opposite - motivation is a by-product of real results!

I can understand that things can seem impossible in the beginning.

The most crucial part is to divide your upcoming work into the smallest tasks possible. This will help you start, which is the key!

Motivation comes from success, specifically from the dopamine hit when you see yourself making progress!

Actions → Results → Motivation

I know it might sound counterintuitive, but action and success is the fuel for more motivation, and ultimately for more action 😊 

How can I get the work done?

1. Design your environment

In order to get more things done you need to start with creating a proper environment for yourself. It’s almost impossible for me to get the work done, when the surrounding place is not optimal for me 🙈.

I am working 100% remotely, that’s why carefully designed my desk space.

You can find my current setup here: https://www.dyguda.com/uses/ 

My desk setup in ‘23

2. Sound / Silence

Depending on the preferences - one person likes working with silence, the other one with smoothing jazz in the background, yet another one with dubstep… no matter the preference I’d encourage you to try a different route and see how it will influence your mood/focus.
I’d myself went through couple of phases… currently the best focus I get is when I am using my ANC headphones (Bose 700) in combination with Focus music from Endel.io.

Yes, I am using ANC headphones even though I am working 100% of the time from home. It helps me focus.

3. Do not disturb

As I have already written in previous issue, the one of the keys to focus is distraction free environment. So whenever I work I am putting my devices into Do not disturbed mode. I am working on a macOS and I’ve created a shortcut that turns this mode on both my phone and laptop and I don’t get any of the notifications. I am controlling the notification, not the other way around.

Resource roundup

A collection of links to stuff I think are worth sharing:

📺️ [Productivity] Why motivation is a myth - Ali Abdaal - Watch here

🎧 [Podcast] EPIC episode of Huberman Lab podcast with Dr. Adam Grant - Listen on Spotify

📚 [Productivity] I am reading Atomic Habits by James Clear - Grab your copy 

I hope I’ve earned the privilege of your time,

Marcin

Welcome to the Issue #2 of The Blend ☕!

I think it’s worth starting with a quote

Last couple of weeks were a bumpy ride with my health so I did not achieve the goals I've set for myself when it comes to writing.

This newsletter is also my way of moving forward, growing, and creating a community of people who are interested in similar things. I've decided to write it in English to reach a much broader audience from the very beginning.

Focus and mindfulness in productivity

Productivity is the category I love exploring from many angles. There are frameworks, tools, and exercises that can help you train your focus with the outcome of increased efficiency.

Focus training is as important as physical training. We live in a world where we are bombarded with notifications, distractions, and information. It's really hard to cope with all that on a daily basis.

As always, the journey starts with looking at yourself, your "technology hygiene," energy levels or even emotions.

I have a challenge for you!

It may sound silly, but that doesn't mean it's easy! When you try it, you will realize how hard it is to achieve. This exercise is great for training your concentration. It helps you channel your attention where you need it the most.

Changes in my environment started with being conscious about my phone. The first step in maximizing my efficiency was to remove the apps I did not need and turn off the notifications for the apps I was using. BUT I wanted to give them my attention only when I wanted, not when they sent the alert.

1. I have removed Facebook and other social media apps (apart from Instagram, where I showcase my work) - and to be honest, with FOMO in the first couple of days/weeks, I never looked back! One of the best decisions I've made.

2. I have turned off notifications for almost all the apps - I've left the one that was sending information from my daughter's kindergarten 🙂 and my email app (but I will follow up on that in future Issues!).

It felt really good to finally break free from being a slave to your phone.

This first step, was rather a giant leap when it comes to my attention span. It improved greatly, showed me that FOMO is pointless and insignificant. It turned out I am not missing out on anything and nothing happens if I don’t answer the message right away.

In the next issue of the Blend, I will share with you additional tips, tricks, things, and tools that I use on a daily basis to help me boost my productivity.

Resource roundup

A collection of links to stuff I think are worth sharing:

• [Productivity] Make Time - great book that provide insights on how to prioritize tasks, eliminate distractions, and make time for what truly matters.

• [Apps] Solid Apps - set of beautiful apps for you iOS and macOS

• [Life Hack] Career advices that doesn’t suck Read more

• [Mental Health] Huberman Lab - Breathing for Mental & Physical Health & Performance - You’ll be getting much more link to Huberman Lab from me. Great source of knowledge about different tools that affect our daily life and productivity. Highly recommend!

Thank you for your time and attention, I really appreciate it.

Marcin

☕

Welcome to the first ever Issue #1 of The Blend ☕!

In this issue, I am excited to announce that I will be writing about a wide range of topics related to business, product management, process management, productivity, product reviews etc.

As a business enthusiast, I will be sharing insights and tips on how to succeed in the competitive world of business. From effective marketing strategies to leadership techniques.

In addition, I will delve into the realm of product management, discussing best practices for creating and launching successful products. Whether you are a beginner or an experienced product manager, you will find practical advice and innovative ideas to enhance your skills.

Process management is another topic that I will be exploring in this issue. From streamlining workflows to optimising efficiency, I will do my best to provide valuable strategies to help you improve your business processes and achieve better results.

Productivity is a key factor in any successful business, so I will be sharing proven techniques and tools to boost your productivity levels. From time management tips to effective goal setting, you will discover actionable steps to maximize your output and achieve your business objectives.

Furthermore, I will be conducting product reviews, giving you an honest and unbiased assessment of various products and services in the market. Whether you are looking for the best project management software or productivity tools.

As part of my commitment to sharing knowledge and resources, I will be curating a list of valuable links, books, and articles that you can explore for further learning. From industry-leading blogs to insightful books, you will have access to a wealth of information to expand your knowledge and stay ahead of the curve.

I hope you are as excited as I am about the content I will be sharing in this issue. Stay tuned for insightful articles, practical tips, and valuable resources that will empower you to thrive in the world of business.

Let this #1 newsletter issue be the first of many paths in front of me 🙂

Tim Urban - x.com

Resource roundup

A collection of links to stuff I think are worth sharing.

• [Business] Thoughts on PMF (Product-Market Fit) - by the amazing Stay SaaSy

• [AI] How generative AI works? Read here 

• [Productivity] “What is not measured, cannot be improved” - there is not more than 24h within a day, and if we want to improve ourselves we need to start measuring what we spend our time on. Rize - is the application that will help you understand that

• [Health] Foundation training by Dr. Eric Goodman - this training has helped me with my backpain. Highly recommend!

Thank you for your time,

Marcin