Biases – how do you overcome them?

Posted Leave a commentPosted in quick thoughts

The list of biases that sound very familiar to many of us:

  • Representative bias leads to a snap judgment on a question based on its apparent similarity to an earlier matter.
  • Cognitive dissonance leads to an avoidance of uncomfortable facts that contradict one’s convictions.
  • Home country bias and familiarity bias lead to an avoidance of anything outside one’s comfort zone.
  • Mood bias, optimism (or pessimism) bias and overconfidence bias all add a note of irrationality and emotion to the decision-making process.
  • The endowment effect causes people to over-value the things they own just because they own them.
  • Status quo bias is resistance to change.
  • Reference point bias and anchoring bias are tendencies to value a thing in comparison to another thing rather than independently.
  • The law of small numbers is the reliance on a too-small sample size to make a decision.
  • Attachment bias is a blurring of judgment when one’s own interests or a related person’s interests are involved.
  • Media bias and Internet information bias represent uncritical acceptance of widely-reported opinions and assumptions.

It’s not that easy to overcome them, I think the only thing to do is to constantly review all the possible data (positive, negative, or lack of it), make a decision, and move on.


Posted Leave a commentPosted in quick thoughts

Fivetran founder and CEO George Fraser explains how and why the pipelines that move data from source to storage — both data lake and data warehouse — have changed from the often custom and cumbersome process of ETL (extract-transform-load) to the more standardized and scalable ELT (extract-load-transform).

We use to enable easy access to various data sources and achieve the flexibility we need

Reusable digital identity is the future

Posted Leave a commentPosted in product

I’ve spent last 3 years working with distributed technology (a.k.a blockchain), cryptography and new business models. It enables us to leverage the power of self-sovereign digital identity and I strongly believe that this is the future. If you want to learn more about that please follow my work at

Additional proof that reusable digital identity is the future, this time from fintech. Onfido, Deloitte, and Evernym have recently announced the positive results of their Financial Conduct Authority (FCA) regulatory sandbox pilot, confirming that reusable digital identity solution has been proven with market participants.

My question to business owners: would you implement a reusable digital identity solution? How do you think it would help your business?

For those who are less familiar with the concept, here’s the problem. To access any online service, you need to prove your identity by creating a new profile and re-verify it for each service. With dozens of services and accounts (almost 200 for an average business user), it becomes a headache. The more complex is the registration process, the higher are the chances user will abandon it even before sign up. 

OAuth may be a solution to some extent (used as social login by Google, Facebook, Twitter), but the amount and type of data are limited. It’s just a way to share your social profile, which is also completely controlled by the service providers and utilized for their benefit. 

Self-sovereign reusable digital identity goes a step further: the profile is controlled solely by a user and can be filled with any data. Users get the ease of use (no need to register and verify identity every time they use a new service) and businesses profit by trustworthy user profiles while reducing onboarding cost and other operational challenges.

Product delivery questionnaire

Posted Leave a commentPosted in management

When I join product team or company here is the list of questions i have in my mind. What do you think about that? Do you think some questions are not relevant? Is there anything you would add?

I. Provisioning

  1. Do you use public cloud service providers?
  2. Are you considering building private cloud?
  3. Are you using containers?
  4. Please describe infrastructure provisioning process from idea to deployment
  5. Please describe any needed areas of improvements/shortcomings of the existing infrastructure
  6. What is the lead time required to provision a new production environment or enhancement?

II. Operations

  1. Please describe how do you plan your capacity? (decision making process, how far ahead, how often, with whom?)
  2. Please describe your disaster recovery strategy, including system backup/restore procedures, simulation of disasters… (how often? who initiates?)
  3. Please describe any dependencies that need to be managed as part of deployment (e.g. CDN, caching 3d party services, …)
  4. Please elaborate on how broadly you’re using opportunities to choose external service providers. Why? What type and size of projects?
  5. How do you ensure that your solution is resilient?

III. Quality assurance

  1. Please describe your quality assurance process: who, what, how, …
  2. What is definition of quality in your team? (SLOs)
  3. Please describe your test planning. Each sprint, month?
  4. How Business/Product people are involved in quality assurance? By whom?
  5. Please describe tools/services used for quality assurance.
  6. What is the percentage of your environment is covered by automated tests?
  7. How often tests are executed?

IV. Continuous integration

  1. Please describe the CI process implemented in your team (how code gets from developer workspace to shared repository)
  2. Please describe the frequency of builds. Why?
  3. Please describe the extent of automated testing
  4. Please describe tools/services used for CI process
  5. Please describe any needed areas of improvements/shortcomings of the existing CI environment/process

V. Continuous delivery (Deployment automation)

  1. Do you have downtimes during deployment? (How long?)
  2. Please describe the extent of deployment automation within the development, staging and productions environments
  3. Please describe the frequency of deployments
  4. Please describe any cases of manual deployments
  5. Please describe the ways used to document deployments
  6. Please describe the tools/services used for deployment automation
  7. Please describe any needed areas of improvements/shortcomings of the existing deployment automation process
  8. Please describe how your deployment changes in case of major changes that require infrastructure or application architecture alterations
  9. What is your maintenance/downtime window and how it relates to automated deployments

VI. Configuration management

  1. Please describe the extent of configuration management within the development, staging and productions environments. How? Who? When?
  2. Please describe the frequency of configuration updates
  3. Please describe any cases of manual configuration changes
  4. Please describe the ways used to insure configuration consistency
  5. Please describe tools/services used for configuration management
  6. Please describe any needed areas of improvements/shortcomings of the existing configuration management process

VII. Monitoring and logging

  1. Please describe the extent of monitoring and logging within the development, staging and productions environments. Types of metrics, frequency, size of logged data, period of time
  2. Please describe who and how uses information? What decisions are made using this information? How often (sprint, month, quarter)?
  3. Please describe who is defining what and how to monitor/log
  4. Please describe tools/services used for monitoring and logging
  5. Please describe any needed areas of improvements/shortcomings


  1. Do you understand benefits of building APIs? Is your functionality covered with APIs?
  2. Do you have geographically distributed teams? Do you have many UIs (mobile, desktop)?
  3. Does anyone outside your organization would like to access your data and workflows in a programmatic way?
  4. Do you have platform team to work on following services: infrastructure, guidelines, development/configuration portal?
  5. Have you established API community to drive the topic across organization: education, contribution to common platform services?


Typically it reveals following issues:

  1. Missing (or understaffed) service oriented platform teams that focus on building self-service solutions for product teams.
  2. No ability to purchase/rent needed services as temporary solution before internal service teams are established properly.
  3. Quality is not measured which makes it (almost) impossible to prioritize non-functional (scale, technical debt, increased usage) improvements.
  4. No multifunctional teams with a mix of #1 and #2 leads to additional stress on teams responsible for a service due to additional headache of prioritizing scarced resource. It also reduces possibility of exchanging feedback between product teams and service teams, which is crucial for building internal services right.
  5. (Almost) no focus on automating activities related to software delivery and maintenance which increases delays and manual work as solution complexity and usage increases.

More lessons learned –

Network structure – 11 lessons learned

Posted Leave a commentPosted in management

1. Autonomous & multifunctional teams

Having all necessary skills in one place allows you to have hyper performing teams able to handle complex tasks. This can be achieved if such environment is created for teams:

  • Ability to make decisions on a timely manner and with maximum return on value
  • Technical and organizational autonomy to deliver on demand
  • Focus on clearly defined area to avoid context switch
  • Possibility to acquire all required skillset to enable autonomy and reduce dependencies
  • Service oriented approach which brings value both internal and external

2. Value/Service delivery oriented teams

Main benefit of such setup is reduction of functional/component (which typically are valuable only in combination) dependencies because teams are forced to exchange valuable services with each other.

Important to keep in mind that it is still a system of mutually dependent elements. It means that it is crucial to operate with respect to the capacity of the teams that you are dependent on. Negative effect of sub-optimization is amplified by fast pace of autonomous network elements.

It requires to adjust behavior, and instead of putting all effort on performing local optimizations to advocate and strive for solving identified bottleneck in the whole structure.

One sample could be hiring. Instead of hiring into your area, hire where bottleneck is or even form a new missing entity. Such actions will optimize whole value delivery

3. Common target

Whole activity of a network must be aligned to a common target. If there is no common goal defined network structure will perform only slightly better comparing to conventional organization (where each function optimizes it’s behavior according their KPIs). Positive effect is driven by focus on value delivery for identified users.

Even if you do not utilize all benefits of network structure you at least will achieve following:

  • Clear cost structure: teams are organized around value delivery and 100% focused on a single purpose
  • Clear communication map: easy to understand who is covering which areas
  • Easier to notice not covered areas, dependencies and

You can make a decision on a strategic level in <10 minutes for a scale of 400 people by just looking at a couple of pages in confluence (or other team collaboration solution) without diving into complex excel files and diagrams.

4. Strive on being a team

It is important to take personal responsibility for every leader of network element and make an effort to act as a team. Team typically shares following characteristics as minimum (if compared to a group):

  • aligned goal,
  • optimizing the whole,
  • supporting

5. Fire fast

The only way to save the box of apples is to throw away rotten ones. By “rotten” in this context I mean:

  • not acting upon achieved agreements,
  • acting according own agenda,
  • not adapting behavior according raised expectations,
  • not learning.

6 Constraints

No system cannot operate without constraints. It is needed to eliminate entropy and to keep the focus of the whole. The most important constraint is common target.

Other constraints play key role in establishing stability because they set rules for communication between elements.

Includes, but not limited to: organizational level artifacts and deliverables, KPIs and/or Service Level Objectives, agreements, dependencies, set of internal services. Each element must expose following artifacts publicly available:

  • Purpose aligned with common target
  • List of stakeholders (clients and dependencies)
  • Service/Product catalog
  • Team structure
  • Roadmap
  • Business KPIs
  • SLOs and Non functional requirements
  • High-level architecture

7. Quality

Quality must never be opinion based. It must be measurable and agreed set of clearly defined metrics that are communicated to stakeholders, publicly visible and tracked in real-time.

There always must be a professional included in a team who understands what quality assurance as discipline means and knows all set of practices that can and should be applied at the right moment of product/team evolution.

Typical mistake is to measure quality with # of bugs. If your team relies mainly (or sometimes only) on this metric, it means there is no agreed quality definition in the team.

Things mentioned are important and beneficial for conventional structure, but vital for network structure because of service oriented approach.

8. Internal services/platforms are critical

It is critical to establish and properly staff internal service/platform teams as soon as possible. It will increase speed and efficiency of the rest of organization. Such internal services cannot be avoided and must be used across company.

It can be useful (time to market, lack of experience and etc.) to use 3d party vendors or build custom solution as a temporary decision while internal service is being developed.

9. “API”

This is foundation of network structure. Contexts must be separated by programming interfaces. It gives possibility to:

  • have autonomous teams,
  • control dependencies with other teams,
  • react faster to market needs due to proper technical decomposition,
  • apply the best technologies and tools for specific challenge,
  • reduce unnecessary communication and coordination (the most important!) among teams,
  • easily add more teams with increasing returns,
  • keep innovating and reduce unknown side effects due to smaller codebase.

10. Chaos in da house

Assumptions that things do not change and can be finalized are wrong. It applies both for work structure and technical solution.

Way of work. Network structure is dynamic as it consists of autonomous elements not fixed functions which can be changed/adjusted based on business needs.

Technical uncertainty. Capacity, stress and resilience tests are new practices that must be introduced and performed periodically. This is the only approach that will help to: ensure technical excellence, identify bottlenecks, visualize dependencies and ensure right level of automation in all teams.

11. Building an internal service/platforms is difficult

Because it requires to act differently (not typical for internal teams in conventional structure):

  • Identify users
  • Understand their problems
  • Build a solution for those problems (not ideal solution)
  • Deliver value as early as possible (typically pick to work on ideal solution)
  • Continuously work with users in gathering feedback, sharing knowledge, organizing meet-ups and etc. (the most difficult)

This is big behavioral shift from a conventional functional/component team that focuses only on development into a multifunctional team which spends a lot of time on pre and post development activities.

12. Resources that I was inspired by

Here is possible implementation of network structure –

It was inspired by following material:

Recent findings which show things are moving that direction: