Browsing Category

Career

@MIT, Career, IT is business

@MIT: Cloud & DevOps – Part 8

August 16, 2020

@MIT series is a group of articles being written to describe my learning path attending to the Cloud & DevOps: Continuous Transformation at the MIT.

This article at a glance – TL;DR

The Cloud Native foundation as a good source to check new moves from the cloud industry

The content

  1. Cloud-Native Computing Foundation: For an application to be considered truly Cloud Native they need to be:
    1. Built for fault tolerance
    2. Horzontally scalable
    3. Written in a manner that takes full advantage of what cloud providers have to offer.
  2. Cloud Native Applications prioritize the following:
    1. Speed
    2. Short cycles
    3. Microservices
    4. Loosely coupled
    5. DevOps
  3. Pet vs cattle way of handling our servers:

As a developer, you care about the application being hand-cared for − when it is sick, you care of it, and if it dies, then it is not easy to replace. It’s like when you name a pet and take care of it; if one day it is missing, everyone will notice. In the case of cattle, however, you expect that there will always be sick and dead cows as part of daily business; in response, you build redundancies and fault tolerance into the system so that ‘sick cows’ do not affect your business. Basically, each server is identical and if you need more, you create more so that if any particular one becomes unavailable, no one will notice.

Cloud native action spectrum:

Cloud native roadmap of adoption (the majority of companies are on step 4):

There’s a landscape map listing tons of vendors on the cloud native foundation for each specific need: http://landscape.cncf.io

Exercises and Assignments

  • Assignment: Create a presentation showing the push you are planning for your company. Think about steps, risks, mitigations, and how you plan to lead the journey. Think about the presentation as if you were presenting it to your CEO or a client.
@MIT, Career, IT is business

@MIT: Cloud & DevOps – Part 7

August 8, 2020

@MIT series is a group of articles being written to describe my learning path attending to the Cloud & DevOps: Continuous Transformation at the MIT.

This article at a glance – TL;DR

Several cases of Agile adoption in a set of big and mid-size companies. Also presented key benefits, challenges and outputs of an agile adoption

The content

Today, over 50% of the Fortune 500 companies from the year 2000 no longer exist. GE is stumbling. BlackBerry (RIM) is gone, and so is most of Nokia, raised to a $150 billion corporation. (…) John Boyd developed a methodology for operating in such situations, called the OODA Loop. The speed of executing the loop is the essential element of survival. It involves testing one’s premises by actual Observation, Orienting your corporation with respect to the situation. Then Deciding on a course of action, and then executing that plan by Acting. This is the meaning of being Agile. (…) Data is the new gold.

MIT – Cloud & DevOps course – 2020

Agile Adoption

Pros of agile software development:

  • Customers have frequent and early opportunities to see the work being delivered and to make decisions and changes throughout the development of the project.
  • The customer gains a strong sense of ownership by working extensively and directly with the project team throughout the project.
  • If time to market is a greater concern than releasing a full feature set at initial launch, Agile is best. It will quickly produce a basic version of working software that can be built upon in successive iterations.
  • Development is often more user-focused, likely a result of more and frequent direction from the customer

Cons of Agile Software Development:

  • Agile will have a high degree of customer involvement in the project. It may be a problem for some customers who simply may not have the time or interest for this type of participation.
  • Agile works best when the development team are completely dedicated to the project.
  • The close working relationships in an Agile project are easiest to manage when the team members are located in the same physical space, which is not always possible.
  • The iterative nature of Agile development may lead to frequent refactoring if the full system scope is not considered in the initial architecture and design. Without this refactoring, the system can suffer from a reduction in overall quality. This becomes more pronounced in larger-scale implementations, or with systems that include a high level of integration.

Managing Complexity of Organizations and operations

As companies grow, their complexity grows. And they have to manage that complexity, otherwise, it’s gonna turn into chaos. The problem is that they usually manage that putting processes in place: you have to sign X docs, follow Y procedures, etc. The problem is that we tail employee freedom, and the side effect is that the high performing employees tend to leave our company.

Netflix’s solution to this scenario was different. They decided to let the smart workers manage the complexity instead of putting processes in place.

The problem for the traditional approach is that when the market shifts we’re unable to move fast. We have had so many processes and fixed culture that our teams won’t adapt and innovative people won’t stick to these environments.

That leads us to three bad options of managing our growing organizations:

  1. Stay creative and small company (less impact)
  2. Avoid rules (and suffer the chaos)
  3. Use process (and cripple flexibility and ability to thrive when the market changes)

Back to Netflix case: they believed that high performing people can contain the chaos. With the right people, instead of a culture of process adherence, you have a culture of creativity and self-discipline, freedom, and responsibility.

Comparing waterfall and agile software development model

Source:

Exercises and Assignments

  • Assignment: Write a summary about two articles suggested by the MIT that highlight the complexity of turning Agile that some companies faced and how they are thriving.

Resources

All the resources used to reach the results above are stored in this GitHub repository: https://github.com/guisesterheim/MITCloudAndDevOps

@MIT, Career, IT is business

@MIT: Cloud & DevOps – Part 6

August 2, 2020

@MIT series is a group of articles being written to describe my learning path attending to the Cloud & DevOps: Continuous Transformation at the MIT.

This article at a glance – TL;DR

Introduced the serverless paradigm, pros and cons, limits and the evolution to reach it

The content

  1. Serverless computing is a Cloud-based solution for a new computing execution model in which the manager of the server architecture and the application developers are distinctly divided. A frictionless connection exists in that the application does not need to know what is being run or provisioned on it; in the same way that the architecture does not need to know what is being run.
  2. The journey that led us to serverless (image below).
  3. A true microservice:
    1. Does not share data structure and database schema
    1. Does not share internal representation of objects
    2. You must be able to update it without notifying the team
  4. Serverless implications:
    1. Your functions become Stateless: you have to assume your function will always run a new recently deployed container.
    2. Cold starts: since every time your function will run in a new container, you have to expect some latency for the container to be spun up. After the first execution, the container is kept for a while, and then the call will become a “warm start”.
  5. Serverless pros:
    1. Cloud provider takes care of most back-end services
    2. Autoscaling of services
    3. Pay as you go and for what you use
    4. Many aspects of security provided by cloud provider
    5. Patching and library updates
    6. Software services, such as user identity, chatbots, storage, messaging, etc
    7. Shorter lead times
  6. Serverless cons:
    1. Managing state is difficult (leads to difficult debug)
    2. Complex message routing and event propagation (harder to track bugs)
    3. Higher latency for some services
    4. Vendor lock-in
  7. More on serverless: https://hackernoon.com/what-is-serverless-architecture-what-are-its-pros-and-cons-cc4b804022e9
From monolith to serverless journey

Exercises and Assignments

  • Assignment: Deploy an existing application to AWS using Lambda and DynamoDB to show a Pacman Game. A few screenshots below:

Resources

All the resources used to reach the results above are stored in this GitHub repository: https://github.com/guisesterheim/MITCloudAndDevOps

@MIT, Career, IT is business

@MIT: Cloud & DevOps – Part 5

July 22, 2020

@MIT series is a group of articles being written to describe my learning path attending to the Cloud & DevOps: Continuous Transformation at the MIT.

This article at a glance – TL;DR

Introduced the regular high-ground phases of a Digital Transformation (and cases for exploring them), which are:

1 – Initial Cloud Project

2 – Foundation

3 – Massive Migration

4 – Reinvention

The content

  1. Cloud computing services are divided in three possible categories:
    • IaaS – using the computational power of cloud computing data centers to run your previous on-prem workloads.
    • PaaS – using pre-built components to speed up your software development. Examples: Lambda, EKS, AKS, S3, etc.
    • SaaS – third-party applications allowing you to solve business problems. Examples: Salesforce, Gmail, etc.
    • XaaS – Anything as a service.
  2. An abstraction of Overall Phases of adoption:
    • 1 – Initial Cloud Project – Decide and execute the first project
    • 2 – Foundation – Building blocks: find the next steps to solve the pains of the organization. Provide an environment that makes going to the cloud more attractive to the business units. Examples: increase security, increase observability, reduce costs.
      • 1st good practice: During this phase, you can create a “Cloud Center of Excellence” committee to start creating tools to make the cloud shift more appealing to the rest of the organization.
      • 2nd good practice: Build reference architectures to guide people with less knowledge.
      • 3rd good practice: Teach best practices to other engaging business units.
    • 3 – Migration – Move massively to the cloud
      • One possible strategy is to move As Is and then modernize the application in the future (the step below).
    • 4 – Reinvention – modernize the apps (here you start converting private software to open source, Machine Learning, Data Science, etc).
    • See the picture below for an illustration of these 4 steps:
Phases of Digital Transformation, and time and value comparison
  1. The pace of adoption is always calm. Even for aggressive companies, like Netflix that took 7 years to become a cloud-first company.
  2. Microsoft case (highly recommended read):
    • Principles for their “shift left” on number and coverage of tests:
      • Tests should be written at the lowest level possible.
      • Write once, run anywhere including the production system.
      • The product is designed for testability.
      • Test code is product code, only reliable tests survive.
      • Testing infrastructure is a shared Service.
      • Test ownership follows product ownership.
    • See below two pictures of (1) how Microsoft evolved their testing process model and (2) the results they achieved.
1 – How Microsoft evolved its testing model
2 – Microsoft results
  1. Layers of test (based on Microsoft example):
    • L0 – Broad class of rapid in-memory unit tests. An L0 test is a unit test to most people — that is, a test that depends on code in the assembly under test and nothing else.
    • L1 – An L1 test might require the assembly plus SQL or the file system.
    • L2 – Functional tests run against ‘testable’ service deployment. It is a functional test category that requires a service deployment but may have key service dependencies stubbed out in some way.
    • L3 – This is a restricted class of integration tests that run against production. They require full product deployment.
  2. General Electric unsuccessful case:
    • GE failed because, despite having created a new unit for the digital transformation initiative, it inherited the culture of the GE Software.
    • Why digital transformation initiatives fail?
      • Lack of business focus.
      • Lack of alignment of plans and practices between the new and the legacy.
      • Not empowering developers.
      • Not experimenting.
  3. Netflix case:
    • Netflix introduced Chaos Engineering techniques: 
      • The best way to avoid failure is to fail constantly
      • The Chaos Monkey’s job is to randomly kill instances and services within our architecture. If we aren’t constantly testing our ability to succeed despite failure, then it isn’t likely to work when it matters most in the event of an unexpected outage
    • Simian Army is the evolution of the Chaos Monkey.

Exercises and Assignments

  • Assignment: Create a self case study containing the given structure:
    • Brief description of the company (attaching web link if possible)
    • Introduction
    • Description of the company’s challenge
    • Solution/Project stages/Implementation
    • Risks
    • Mitigations
    • Conclusion

Resources

All the resources used to reach the results above are stored in this GitHub repository: https://github.com/guisesterheim/MITCloudAndDevOps

@MIT, Career, IT is business

@MIT: Cloud & DevOps – Part 4

July 14, 2020

@MIT series is a group of articles being written to describe my learning path attending to the Cloud & DevOps: Continuous Transformation at the MIT.

This article at a glance – TL;DR

The DevOps revolution: importance of continuous feedback, data-driven decisions, pillars of DevOps and metrics

Main quote

Today, software development is no longer characterized by designers throwing their software ‘over-the-wall’ to testers repeating the process with software operations. These roles are now disappearing: today software engineers design, develop, test and deploy their software by leveraging powerful Continuous Integration and Continuous Delivery (CI/CD) tools

MIT – Cloud & DevOps – Continuous Transformation course – 2020

The content

  • DevOps key metrics to be watched:
    • Delivery lead time (measured in hours) – e.g.: how much time is taken between the task registered on the management tool until it reaches production?
    • Deployment frequency – how many deploys to the Production environment we make weekly.
    • Time to restore service – how many minutes we take to put the service back to work when something breaks.
    • Change fail rate – how many of our deploys to the Production environment cause a failure.
  • Importance of information flow. Companies have to foster an environment of continuous feedback and empowerment. It allows everybody to solve problems and suggest innovation within their area of work.
  • Data-driven decision making
  • Pillars of well designed DevOps:
    • Security
    • Reliability
    • Performance Efficiency
    • Cost Optimization
    • Operational Excellence
  • A good example of a well-designed pipeline abstraction:
    • Version control – this is the step when we retrieve the most recent code of versioning control.
    • Build – building the optimized archive to be used to deploy.
    • Unit test – running automated unit tests (created by the same developer that created the feature).
    • Deploy – deploy to an instance or environment that allows it to receive a new load of tests.
    • Autotest – running other layers of the test (stress, chaos, end to end, etc)
    • Deploy to production – deploy to the final real environment.
    • Measure & Validate – save the metrics of that deploy.
  • There are companies that are up to 400x times faster on having an idea and deploying it to production than traditional organizations.
  • Several analogies between Toyota Production system and cases (below) and DevOps:
    • Just in Time
    • Intelligent Automation
    • Continuous Improvement
    • Respect for People
  • Theory of Constraints:
    • You must focus on your constraint
    • It addresses the bottlenecks on your pipeline
  • Lean Engineering:
    • Identify the constraint
    • Expĺoit the constraint
    • Align and manage the systems around the constraint
    • Elevate the performance of the constraint
    • Repeat the process
  • DevOps is also about culture. Ron Westrum’s categories for culture evolution:
  • Typical CI Pipeline:

Exercises and Assignments

  • Assignment: Creating a CircleCI automated pipeline for CI (Continuous Integration) to checkout, build, install dependencies (Node app) and run tests.

Resources

All the resources used to reach the results above are stored in this GitHub repository: https://github.com/guisesterheim/MITCloudAndDevOps

@MIT, Career, IT is business

@MIT: Cloud & DevOps – Part 3

July 7, 2020

@MIT series is a group of articles being written to describe my learning path attending to the Cloud & DevOps: Continuous Transformation at the MIT.

This article at a glance – TL;DR

Docker, Containers Orchestration and Public Key Infrastructure (PKI)

The content

  • How the stack of software components used to run an application got more and more complex when compared to past years.
  • In past years a huge number of web applications used to run on top of LAMP (Linux, Apache, MySQL, and PHP/Pearl). Nowadays we have several different possible approaches for each one of the layers of this acronym.
  • Containers are the most recent evolution we have for running our apps. They followed these steps:
    1. The dark age: undergoing painful moments to run your app on a new machine (probably using more time to run the app than actually writing it).
    2. Virtualizing (using VMs) to run our apps, but having the trade-off of VMs’ slowness.
    3. Containers – They are a lightweight solution that allows us to write our code in any operating system and then rerun it easily in another operating system.
  • The difference between Virtual Machines and Docker:
    • Virtual Machines = Applications + Libraries + Operating System.
    • Docker = Applications + Libraries.
  • The analogy between the evolution of how humanity solved the problem of transporting goods across the globe using containers (real and physical containers) compared to how software developers used the containers abstraction to make our lives way easier when trying to run an application for the first time.
  • Kubernetes is introduced and the benefits approached:
    • Less work for DevOps teams.
    • Easy to collect metrics.
    • Automation of several tasks like metrics collecting, scaling, monitoring, etc.
  • Public key infrastructure:
    • More and more needed interaction machine-to-machine requires more sophisticated methods of authentication rather than user and password.
    • Private and public keys are used to hash and encrypt/decrypt messages and communications.

Exercises and Assignments

  • Exercise 1: Running a simple node app with docker (building and running the app)
  • Assignment:
    1. Build a docker image
    2. Publish it to dockerhub.com
    3. Run a local ghost blog using docker
    4. Publish a sample post 

Resources

All the resources used to reach the results above are stored in this GitHub repository: https://github.com/guisesterheim/MITCloudAndDevOps

@MIT, Career, IT is business

@MIT: Cloud & DevOps – Part 2

July 1, 2020

@MIT series is a group of articles being written to describe my learning path attending to the Cloud & DevOps: Continuous Transformation at the MIT.

This article at a glance – TL;DR

The course has two big parts: (1) technical base and (2) business applications and strategies

The second module introduces benefits, trade-offs, and new problems of developing applications for scaling. It also covers the complexity of asynchronous development.

One more technical assignment is present, and it’s based on Node to focus on Javascript since it’s the most used programming language nowadays.

The content

  1. To start with, they approached the whole web concept (since its creation by Tim Berners Lee).
  2. The Javascript creation (the most used language for web applications worldwide).
  3. How Google changed the game creating Chrome and the V8 engine.
  4. The creation of Node.JS.
  5. Implementing a simple webserver at Digital Ocean.
  6. The evolution of complexity between the web first steps and the day we are right now: Open Source, JSON protocol, IoT and Big Data and Machine Learning more recently.
  7. The world of making computation in an asynchronous world/architecture.

Exercises and Assignments

  • Exercise 1: forking a project at GitHub.com and sending a pull request back.
  • Assignment 1: Running a simple node application locally (a PacMan game) to understand the communication between the client (browser) and server (Node.JS), and also retrieving metrics through an endpoint using JSON as a communication pattern.

Resources

All the resources used to reach the results above are stored in this GitHub repository: https://github.com/guisesterheim/MITCloudAndDevOps

@MIT, Career, IT is business

@MIT: Cloud & DevOps – Part 1

June 27, 2020

@MIT series is a group of articles being written to describe my learning path attending to the Cloud & DevOps: Continuous Transformation at the MIT.

This article at a glance – TL;DR

The first module is putting everybody’s knowledge up to date about the internet and software development practices evolution.

Assignments of the first module are simple when technically speaking

The content

Disclaimer: I won’t post the course content and deeper details here for obvious reasons. Everything mentioned here is my learning and key takeaways from each class/content.

The first module is very introductory. Concepts like the internet creation and explanations about how the information flow evolved from the first internet connection to the cloud are approached very briefly.

More than being introductory, it is very straightforward and hands-on (which I consider great). There are forum discussions for the participants to get to know each other, and an open Q&A about the exercises and assignments.

Exercises and Assignments

  • Exercise 1: examining a small JSON file at the Chrome console to understand the JSON pattern and Javascript key concepts.
  • Exercise 2: examining a BIG JSON at the Chrome console to show how things can get complex eventually.
  • Exercise 3: running a Node simple app to analyze the BIG JSON file from exercise 2.
  • Assignment 1: Creating a simple static personal website at Amazon using S3 buckets. My result is here: https://guilherme-mit-module-1.s3.amazonaws.com/color.html
  • Assignment 2: Creating a simple static personal website at GitHub.io. For this one, I went a bit further and added a small set of free static CSS and HTML pre-built to reach something better than just the “hello world”: https://guisesterheim.github.io/

Resources

All the resources used to reach the results above are stored in this GitHub repository: https://github.com/guisesterheim/MITCloudAndDevOps

Career, Entrepreneurship, IT is business, Practical examples

Two main errors your agile project may have right now and how to solve them

March 12, 2020

Doing agile for software development is way beyond leaving the heavy documentation behind and produce more. According to an HBR study of 2018, 25% of enterprise companies are already using agile and 55% are in the process of doing the same. The data doesn’t lie: the masters of DevOps and Agile grow and are 60% more profitable than the rest. Agile brings many benefits, but it also brings new challenges built-in. The single point of adopting agile is already a major challenge. But after them, new challenges are still there and you might not have noted them.

1st – Involuntary blindness from POs

A day in the skin of a PO (Product Owner) is tough. They own the product! And are responsible for its evolution. Basically they are responsible for translating the company’s macro strategy for that product into the actual final product. It sounds pretty simple, but this process is where commonly things get fuzzy. A PO also:

  • Solves questions from the development team on their tasks;
  • Keeps feeding the backlog;
  • Helps the Scrum masters with decisions for prioritization;
  • Eventually, changes prioritization and delivery plans because of special requests from the management;
  • Monitors metrics of the product;
  • Is responsible for meetings with high management to discuss the metrics she’s been monitoring;

Many of the items above would require a person full time working to fulfill it successfully. But given this load of work, the PO often leaves behind one important thing: hearing what the market is saying and still staying aligned with the macro strategy. By that I mean the PO frequently doesn’t have time to think, judge and decide appropriately after a new demand came from a BA (Business Analyst) or high management. Due to lack of time, she leaves behind the most important task of his job, which is enhancing the product. Let’s go over one example to better illustrate:

A page never used in a hotel website

Years ago I was the SM (Scrum Master) leading a team developing a hotel website. I remember as if it was today. We had a big deliver at the end of 3 months and in the last week, my PO brought me the news that we missed one important page to showcase the hotel’s partnership with an entertainment channel. Guess what? We worked several hours more than planned and delivered just a small part of that page. Also kept working on the same page even after the deadline. We released the final page a few weeks later, and I was checking Google Analytics. I found out that that page had less than 5 percent of the website visits.

The summary: we spent at least one entire month of work on a page that less than 5% of our target public was actually interested in. We wasted one month of money for a team with 4 dedicated people. There was no regulatory thing and no contract binding forcing them to have that page live. It was just a request from a board member. In that situation, the PO SHOULD have argued about not doing that and going for the e-commerce system as a priority. This was actually something the users were asking strongly.

But why did the PO let it stay that way? The answer: she didn’t know that page was about so few accesses. She was so dived into the deadline and reports and monitors and tests that she just accepted the request without questioning it. If she had had time to think about it, with the appropriate information from her BAs, she would have taken a better decision.

2nd – Deficient hands-off of tasks from the PO/BAs to the delivery team

The second thing that often breaks plans is when the planning meeting is already going on and the technical team finds out a task is much bigger than the PO/BAs thought at first. When the PO is defining the next tasks for the backlog, she must be well aligned with the software architects. When a major feature (an epic) comes to the table, the technical team has to adapt the software to develop that new task accordingly. Let’s go over one more example:

The “just one more report”

This one happened during a project for one company in the manufacturing industry. The software had been running for months and was stable. We were in a phase of acting over bugs, security and small features. We were also generating some reports for gathering new metrics. When the planning started, our PO explained about the task of adding more columns and creating a new report with charts. The charts were fine, but those new columns were stored in other systems which we didn’t have control over. We had to talk to people on the other software to create an API for us to consume the data, and the simple report took more than a month to be finished.

The interesting part of this example is that the report was promised to be delivered after one week and took almost 2 months. The management had to wait for the new report to take new decisions because of the important information. The change from 1 week to ~2 months created an unneeded discussion between the project team and the management. All of that wouldn’t have happened if somebody with a brief technical vision of the project was involved during the grooming/prioritization of the backlog and had properly communicated with management.

If a task much bigger comes with no previous preparation, it generates delay. The way to solve it is to have technical senior people checking the backlog periodically and being closer to strategic decisions. This way they will be able to anticipate such moves and tackle big tasks little by little.

At last

Agile is not exact sciences. You will have to find your own set of practices that will create your own agile. These are the two main challenges I found are often hidden and people don’t actively tackle them because they don’t hurt at first, but yes have side effects that can turn into a big mess. And what are your main challenges?

Career, Practical examples

6 steps for the best feedback you’ll ever give

November 19, 2019

After some years leading IT teams and dealing with many different scenarios, I’ve been refining the techniques for giving a good feedback. A good feedback session usually has just the last 4 steps written here.

But something happened last week and made me add two obvious steps that are often forgotten before the actual feedback session. Just because giving good feedback is way easier, here I present the steps to give feedback when you need to talk about behavior, a mistake, or even to have a regular talk to help somebody with their career progress.

1 – Build trust

A trustworthy environment is the base for a good feedback moment. There’s an exchange between the one who gives and the one who receives feedback. Who gives it learns and gets experience. Pretty often understands how and why things are going the way they are going, and then has the opportunity to adapt and evolve together (this is part of the leader mission btw). The one who receives the feedback is thirsty for evolution and progress on their career. Usually seeks feedback for improvement constantly. But what if they don’t trust each other? Who gives feedback gets afraid of self-exposure. Fears not being enough to make things happen and help to develop the other side. And who receives feedback easily dives into an ego that will make the suggestion for improvement sound something unreal.

The trust between the two parts is crucial. Do you have trust within your team? Is talking to each one of your team individually part of your routine? Do you enjoy to stay together? Does your team come to ask you a point of view or advice when something goes wrong? Do you back them up when things go wrong or do you expose them? Do you feel like you accomplish stuff together? If the answer is no to a few of the questions, my guess is you don’t have a trustworthy environment.

2 – Set the goal

Since now you have trust, it’s time to together plan how far, how, and why the feedback receiver wants to go. What do they aim? This is the core of what will motivate them. The side missions can be something close to the goal, but the big missions must always be something clearly pointing to the individual goal. As a leader, it’s your duty to understand even if the individual will evolve more with another leader than would with you.

The key to this step is to always have a plan to follow. There is always stuff to be improved. What are the short, mid and long term goals for the one you are giving feedback? Does the feedback make sense when compared to the goals? Once you have the macro plan, SMART activities might help people see progress happening, depending on the team you are leading.

3 – Start with a good point

Ready for the real feedback moment? Why should you start telling something good? Starting by mentioning something the individual does well is a good way to start and to create empathy. You will be showing you recognize the good job being done besides the feedback you are about to give. It will increase the chances of the feedback to be received in a positive way, deeply understood and connected with real scenarios to help you explore the subject even more than what was planned.

4 – Show the FACT

Just show the fact. What happened? Was it a bad posture during a meeting? Was it a delayed task? Did they offend a colleague? Show the problem without judging. Do not make comments about what happened. Just say what has to be said looking in the eyes. It’s something important and has to be understood as a message. Straight.

The fact cannot be something you suspect. If you are not sure, it might be unfair. If you suspect and it’s a reality in your team, just pay more attention and you will see the thing happening. Go back to step 1 and get closer to your team if you don’t see it.

It cannot be something somebody told you. If you go for this way, there’s a huge risk of creating an environment of gossip. And then you’re back to the 70’s leadership style.

5 – Show the impact

Often people who commit mistakes don’t see or don’t want to see the impact. People don’t want to be seen as they are pulling the performance down. Why was the goal, delivery or whatever compromised by the FACT?

Was the fact a lack of commitment? The impact can be the delayed delivery and a bad relationship with your client (internal or external).

Was the fact an argument during a meeting? The impact can be damage to the team relationship.

6 – Build the action plan

You can create the action plan once the fact and impact are understood. What will prevent the same thing to happen once again? What happens if the situation occurs again?

For the action plan, you have to set SMART (specific, measurable, achievable, relevant and time-framed) goals. When you will check again if the issue was solved? If it’s not solved, another feedback session will occur, but if it was solved, it’s important to note and recognize the progress made.