Tymoteusz Motylewski

I love phrases that are short, yet are precisely describing reality.

Often there is a whole story behind it.

The bike-shedding origin story

The governmental financial committee gathers to approve plans for a nuclear power plant. The plant budget is $100 million.

The committee goes through a proposal.

Technology and construction are so complex and expensive that most people don't understand them. Neither how do things work nor what are the consequences nor possible alternatives.

As nobody is also willing to ask questions not to look stupid. The committee approves the plan in 10 minutes.

There is still some time left, so one of the members calls "Let's do something for the staff" and proposes that a $300 shed should be built for employees riding bikes to work at the power plant.

Everybody has a strong opinion about the size, color, material, and design of the bike shed. So the committee is far from a consensus after a few hours of heated discussion. The topic is then postponed to the next committee meeting.

Does it sound familiar?

People tend to spend a huge amount of time discussing trivial but easy-to-grasp issues. Neglecting at the same time far more important and difficult tasks. This is the meaning of "Parkinson's law of triviality" aka the bike-shed effect.

How to escape bike-shedding

Next time you'll find yourself in a futile discussion over an unimportant topic, call it bike-shedding and explain the concept.

1. Agree the topic is unimportant and set boundaries e.g. budget/time

2. Delegate the decision to find the best solution in given boundaries to one person

3. Get back on track focusing on important topics.

Next time it would be enough to just raise a hand and ask "are we bike-shedding here"?

The Internet is full of blogs and podcasts about Agile.

And honestly, I've tried listening to most of them.

But the one I keep coming back to, over and over again, is Drunk Agile by Daniel Vacanti and Prateek Singh.

If you are working in an agile team, here's why I would recommend blocking 30 minutes per month to listen and study every episode:

Reason #1: Humor & whisk(e)y

I like people who have a sense of humor and are not taking themselves too seriously. The convention of casual conversation over a glass of scotch makes the sometimes complex topics easier to digest.

Reason #2: No fluff & nuances

Daniel and Prateek are both speaking from their experience which is quite impressive. They focus on what is important in practice, debunking some myths along the way.

They explain the main concept, but also show nuances of the topic. In contrast to many authors who oversimplify things and try to sell you one-size-fits-all solutions.

I also like how they combine Agile and Lean practices together. Also when talking about tools, practices, or metrics, they always remember about the human factor.

Reason #3: One topic per episode

Each episode is covering one topic. This makes it easier to find recordings about the area I'm learning right now, and allows me to watch them in any order I want.

As an Agile practitioner, I promise—this is one of the most useful resources on the Internet to dive deeper into Agile and Lean. Especially if you feel that Agile is somehow not working for you and your team.

Yes, you're right, this is a GDPR little brother. Effective since May 2022.

Sanctions and penalties

The penalties system is similar to the one introduced in GDPR.

You can be fined up to 4% of your annual turnover, or up to EUR 2 million where turnover information is unavailable.

New requirements for e-commerce owners

1. Product has a promotional price? You have to show the lowest price from the last 30 days before the price reduction.

2. It's not allowed to sell products with very similar packaging but with different compositions in different countries.

3. You must inform the customer what is the main criteria of the search results ranking. It must be communicated if the higher listing can be bought.

4. Your shop has to provide a telephone number as well as an email address.

5. Customer protection rules now also apply to situations where a customer doesn't pay but provides personal data in exchange for a digital product. This means that a customer will be able to cancel the purchase within 14 days without providing a reason and e-commerce needs to clear personal data then.

6. You must ensure that reviews are authentic and, communicate to customers what measures have you taken to ensure that.

Great impact

Similar to GDPR, Omnibus Directive has a major impact on the whole e-commerce industry.

Implementing the rules are often quite costly and risky. It's not defined in detail how the rules should be implemented in real life.

Even popular e-commerce platforms are not yet ready and do not provide the functionality required by the directive.

The Goal

As usual, the goal is noble - to protect consumer rights when shopping online. For example to avoid merchants setting fake price promotions before black Friday.

But are the means justifiable?

It takes 3 options to have a choice.

As a company owner and CTO, I'm constantly being asked to make an either-or decision, picking from two extreme options. I see this pattern everywhere, in contract negotiations, business decisions, software architecture, HR decisions...

When you only see two ways, it's often a false dilemma.

Many times there is a third option that is better for everyone.

It could be an option that combines the advantages of both ways, or just a less extreme version of one, or a completely different approach to solving the problem.

That's why I never take a decision until I see more than just 2 options.

Examples of the 3rd option:

• "either It's my decision or your decision" => it's your decision, but let me advise you before you make it

• "are we buying it or not?" => is rental an option? or negotiate the price

• "are we giving the customer a discount or not?" => give a discount in return for something e.g. public case-study

• "are we doing this risky/expensive thing or not?" => do an experiment, and risk a small budget to reduce uncertainty before going all in

• are we going with this tool or that => can we integrate both? can pick one and change some processes to mitigate disadvantages?

When faced with an alternative, ask yourself a question:

If the third option were possible, what would it look like?

Be creative.

Did leading by example become useless in 2022 and fully remote teams?

Bootstrapping a software development company from 0 to 80 employees, in the last 10 years, was full of hard leadership lessons shaping my leadership style. I always believed that actions are more important than words, thus leading by example felt like a natural path for me.

As an introvert, I preferred to show rather than tell, and help instead of just saying "I care about you".

Then the pandemic started, and we switched from hybrid to fully remote work.

I've noticed that knowing each other and building trust, aligning on goals, and sharing intentions become harder and required more time. It was especially true with new coworkers (we kept growing 30-40% year to year).

I believe it took longer because there were fewer interactions, more async communications, fewer chances for talks unrelated to work over lunch or coffee, and fewer opportunities to see me working, making decisions, etc.

Does it mean that not every leadership style is efficient/optimized for remote work?

Or maybe the "example" part of "leading by example" has to be redefined with a focus on intentionally creating opportunities "to show actions"? Opportunities we took for granted, as they naturally happened when worked from the office.

The part of leading by example about behaving consistently with values is still true and important. And actually should be true for any style of leadership.

What is your leadership style, and how did it change when working fully remotely?

"What are your professional boundaries as a software developer in relation to the customer?"

"Tell me about the situation when you refused a request from the customer" I like to ask such a question when recruiting programmers. Every healthy relationship requires boundaries. Being aware of them and able to enforce them is part of the software craft.

Imagine a customer asking a car mechanic to change the engine oil. But instead of the motor oil, he wants the mechanic to use sunflower oil. "It will be cheaper," he says.

What would the mechanic respond? Would he fulfill the customer's request? Isn't the customer always right?

No mechanic would agree to that. It's clear using the wrong oil would be unprofessional, against the craft.

Yet, It's common for developers, to obey the professional boundaries. Please don't get me wrong, I know It's often done out of good intentions in order to please the customer.

Being professional means refusing to work on unclear tickets

An example from daily life:

Sometimes customers want to rush a ticket that is unclear on the expected outcome, has an unresolved blocker, has ambiguous descriptions, or has no description at all.

Starting working on it will not end well, as it's impossible to fulfill expectations that are not clear.

It's not enough to just say "NO".

Be friendly and proactive.

Propose a solution. Maybe a call to clarify the scope would help, perhaps writing down acceptance criteria will clear expectations, or maybe some research is needed before this ticket can be tackled.

Without knowing what are the boundaries of being professional you end up working hard on things customer didn't want/expect or like.

To make a customer happy long term, you shouldn't always try to please him short-term.

What else do you consider a professional boundary in software development?

Developers who ask the right questions in the right way are getting things done, while others struggle.

During my over 10 years of experience as CTO, I've worked with hundreds of developers from many countries and cultures. For a long time, I was wondering why some are easy to mentor and help and are making rocket-speed careers, while others are stuck.

Both juniors and senior developers will face problems that are new to them.

What makes seniors resolve problems faster is often how they are able to communicate the challenge and ask for help so others understand the problem too.

How to describe a problem so it's easy to get help:

• don't be afraid of asking for help,

• be brief, describe the problem from top to bottom, starting with what are you trying to achieve and why,

• describe the challenge and not your "history of struggle" and emotions,

• give context: e.g. which project or technology, code fragment, error message,

• share what have you tried but didn't work,

• be precise on the language level - e.g. replace pronouns (it, this, stuff, something, ...) with relevant words, and on the technical level - e.g. show the exact command you run

• avoid ambiguous words e.g. when saying "backend" do you mean server behind a proxy, portal admin panel, or something else?

• use the right channel depending on the situation (e.g. start with project chat or technology chat before DM'ing your boss)

• format message for readability e.g. use lists and code highlighting, and re-read the message before submitting it in chat.

if you know how to frame the question, even a rubber duck can aswer you ;)

Explaining problems and asking for help are key communication skills. It becomes even more important when working remotely and communicating asynchronously.

After all, googling or checking Stack Overflow is also about framing the correct question.

"We're already 3 years into agile transformation in our bank, and I hate it"

Said a friend of mine who has over 15 years of experience in managing software projects in different corporations. He complained that now even simple projects take 2 times longer than they used to...

Based on this and similar conversations I have curated a list of the bests ways for a company to make its employee hate agile.

1. Take a random set of procedures and call it an "Agile transformation"

The best way to make it work is to take a well-known, big consulting company to prepare and implement their branded agile framework in your corporation.

Make sure the framework diagram is big as a wall, and that the development team will never ever see or talk to an end-user.

2. Use Agile methods for things they were never designed for

Ignore (or fire) anybody who says that Agile is not the right tool for everything and that it's best for custom development, where discovery process experimentation is important.

Make sure your help desk, operations, and SLA teams start planning all tasks 2 weeks ahead.

3. "Carefully" select the Product Owner

This one is tricky, even if the first two ways were in place, a wrong Product Owner can still make value out of the chaos.

The ideal PO to make everybody hate agile needs to:

• have no sense of ownership,

• be a classic "forward manager" and push every email he gets from any of the stakeholders directly to the team, (the more stakeholders try to force their agenda onto the team the faster they will hate agile),

• have no idea how to asses the business value the team delivers in a given task or iteration,

• and as result can't evaluate business ideas and set priorities for backlog items,

• never negotiate task scope, nor agree to compromises to limit custom development,

• has a "bike-shading tasks" first policy.

Use these 3 methods and make your entire crew hate agile in no time!

I bet your shop relies on at least 3 external services.

Being in the e-commerce industry for over 10 years I helped plenty of customers tune the performance of their shops and increase turnover as a result. Checking and monitoring dependencies is a crucial part of the investigation.

Today e-commerce systems are heavily integrated. On one hand, they rely on integrations providing some data or business logic like

• payment gateways,

• pricing,

• inventory,

• order,

• product information,

On the other hand, they rely on infrastructure services like databases or search engines.

Despite every e-commerce has several external dependencies, It's very rare to see proper monitoring of them.

Here are 3 common mistakes made when coping with integrations.

Mistake 1: no monitoring of external systems

It's just flying blind. Not working integration can take down your shop and you will not know why it's not working.

Mistake 2: monitoring "health checks" instead of real API calls

Often external systems come with a "health check" or "status" API which allows you to verify if the service is working. Monitoring it is a good idea, but it just tells you whether it's on or off.

Health checks are often giving false-positive results, as they are implemented to be quick and not to be precise.
I recommend monitoring the error rate for real API calls your application is performing as an addition to the health checks.

Mistake 3: not monitoring the performance of external API

Your shop conversion might drop drastically even if the external API returns proper results, but slower than usual.

In one of our recent Magento projects - we found out that the product reservation API was having a few minutes of slowdowns every hour. Response time went up from 100ms to 2s, which caused tons of abandoned carts. Customers were reporting issues with checkout, but without monitoring, nobody was able to reproduce it.

Interestingly the performance of the health check endpoint was good and stable - so monitoring just it would not reveal the issue.

Once we provided the chart of the API response times to the vendor, they managed to quickly fix the underlying issue.

Mistake 4: monitoring, but without triggering alerts

Be proactive and instead of just gathering data and drawing nice charts, set automatic triggers when the performance of the external API drops. When possible I'm also adding the API vendor email to the alert recipients, so they can fix the underlying issue right away.

Adding individual tracking codes to newsletter links caused a 3x lower conversion rate.

The customer has reported that his recent newsletter had a big drop in conversion rate in comparison to the previous one.

After checking the performance monitoring tool it became clear that the conversion drop was a result of the landing page being very slow. I knew we had a Varnish Cache in front of the e-commerce so I expected the landing page to appear super fast, in a matter of milliseconds.

Unfortunately, individual tracing codes prevented Varnish from returning the cached version of a page and forced e-commerce to render the landing page again and again for every newsletter user. Varnish is caching pages based on the URL - different parameter in URL means separate cache entry.

As a solution, we've configured varnish to ignore common tracking parameters

Tracking codes are most often used only from the frontend/JavaScript side and they don't influence the page content. This means that they can be ignored/stripped from the URL before Varnish passes the request to e-commerce. And as a result, Varnish delivers a cached landing page for all newsletter recipients in a few milliseconds.

Lessons learned

1. be careful when enabling individual tracking codes in campaign links they can cause the landing page to be slow

2. when using a reverse proxy cache like Varnish, or CDN make sure to ignore common tracking codes from the URL (like utm_medium, gclid, fbclid, pk_campaign) for caching purposes. This will increase the cache hit rate, and make many customers get pages faster

3. monitor the performance of the e-commerce and business metrics like conversion, to detect issues as soon as they appear
   

What really annoys me a lot is when people distract me with chat messages like "Hi", "Can I ask you a question?" or "Have a sec?" and then keep me waiting for the real question.

Does this pattern look familiar to you too?

13:15 John
Hi!
13:18 Bill
...?
14:20 John
Is the demo on Thursday or Friday?
14:22 Bill
Friday

Usually, it's just a few minutes of waiting, but sometimes people get distracted between "hi" and a question, or you don't manage to answer them before they finish the day. As a result, the conversation which should take minutes will continue the next day.

Instead of greeting, ask the question right away!

Of course, if you want to be polite, you can keep "Hi" at the beginning of a question.

13:15 John
Hi! Is the demo on Thursday or Friday?
13:18 Bill
Friday

This change might look like a nothing big at first glance, but It's very important especially when the other person chats with multiple people every day or is in different timezone. Asking the question right away allows for asynchronous communication, and cuts out unnecessary distractions.

To be honest with you, I was also guilty of saying "Hi" way too often. Somehow it felt natural in the conversation. But once I become a leader I started feeling the pain and seeing how much time is lost in waiting and context switching. So now I'm an advocate for the "No Hello" rule.

Project management tools are full of metrics agile team can monitor. Unfortunately, most of them are "post-mortem" metrics, meaning, they are calculated when the ticket is finally done and it's too late to improve the situation.

For example, Cycle Time is useful for retrospectives, and prediction but it doesn't help the team to take action and fix the problem when it appears. Burndown chart will show that progress is low but will not tell which ticket to dive into to improve the flow.

If you are to measure just one metric in your team - make it "work item age".

Work Item Age is a metric showing how long a ticket spends in making. Depending on your flow, you can analyze it for a single kanban column like "in progress" or "in testing" or for the whole process - how long the ticket is already being processed.

There are many reasons why a ticket might be stuck:

• the actual development takes more time,

• there is an external blocker,

• somebody forgot to move the ticket to the next column after finishing working on it,

• it was assigned to the wrong person, and nobody felt responsible for monitoring its progress.

Looking at Work Item Age you can detect right away, which ticket is spending more time in a certain stage than expected. And take appropriate action to fix the problem before it's too late.

Going through the list of tickets with the highest age during daily standup will make the meeting more valuable for the team. And as a bonus, it will make the team focus on speeding up single-piece flow.

From my experience, teams that focused on decreasing work item age saw tremendous improvements in all other flow metrics as a result.

If you are at all interested in lean management and don't know where to start, then you need to clear your calendar and read:

"This is Lean. Resolving the efficiency paradox" by Niklas Modig and Pär Åhlström.

And here's why:

• It's short

• It's using clear, easy-to-understand language,

• contains insightful examples, that everybody can relate to (e.g. efficiency of health care from the patient perspective)

• It will change the way you think about efficiency. It proves that a traditional focus on utilizing resources efficiently (the doctor being busy) is often causing more work to be done in the company, and lover value for the customer (long patients queues, waiting 3 months for a 20min appointment),

• you will understand the basic concepts of Lean Management, allowing you to enter the world of the most widespread management philosophy of our time

Honestly, this book changed the way I look at business — and completely changed my perception of efficiency. And more importantly, It made me curious to dive deeper into lean management and apply the principles in software development.