IT is business, Practical examples

App scaling with fast and reliable architecture

May 9, 2020

The pandemic reality gave a huge push on digital businesses. The companies succeeding right now have strong strategies for digital interaction. More on: McKinsey, McKinsey, The Economist, and CNN Business. But how are they scaling their business (and their applications) so fast in a reliable manner? Prepare your applications (aka our Digital Products) with a fast and reliable architecture. This is a paradigm shift for most companies.

Why should we prepare to scale

Costs. An application not prepared to scale accordingly to its demand will cost more to be kept than others. The cloud advantage must be used at most in this scenario. An example: the websites to buy tickets for concerts spend a huge portion of their time working under low or regular demand. But when a well-known group announces a new concert, thousands of people rush to their environment to get a ticket. (find a similar reading here). A useful analogy: if you don’t prepare your application to scale according to demand, it’s like you are always driving an RV even if you are just going to the supermarket instead of going to vacations. You don’t need to carry 5 or 6 people with you to go to the supermarket. As well as your app doesn’t need to be fully-armed at 3 am.

As we can see in the image below, people use the internet with different intensity according to time each day.

Seattle internet consumption on the first week of January 2020 (from CloudFlare)

Peeks of usage. Maintaining a portal with around 100 visits per day (like my own) is fine. But a different approach will be needed to another one with One Million views on the same timeframe. But more important than that, be prepared for peeks of usage to maintain the brand’s reliability and company growth. Zoom is an excellent successful example of application scaling. But they are the minority amid hundreds of bad examples that are impacting our lives. I.E: check New Jersey’s government ask for help with a very very old application).

How to prepare a fast and reliable architecture

Architecting for scalability

Use the advantages of the cloud’s existing tools. All cloud players have efficient tools for load balancing the application’s requests. Microsoft’s Load Balancer, Google Load Balancing, and AWS Elastic Load Balancing are very easy to set up. Once defined rules for load balancing, auto-scaling groups improve the application power to handle requests. Using the auto-scaling groups you can set different behaviors for your app. Both based on demand from users and also patterns you already know they exist (3 am driving an RV). If all of this is new for you, keep in mind that new solutions bring new challenges. Listed below are few things you have to take a look when setting up auto-scaling behavior:

  • Speed to startup a new server – When you need to scale you probably will need to scale FAST. To help with that, have pre-built images (AWS AMIs) to speed up your new servers boot time. Kubernetes orchestrating your app will also help with this.
  • Keeping database consistency – Luckily the big cloud players have solutions to keep the databases synchronized between your different availability zones almost seamless. But once you start working with multiple regions, this will become one more thing to establish a plan and handle.
  • Keep low latency between different regions – Multiple regions can solve latency for your users, but will bring the latency to you. Once again talking about multiple regions (either if you are building a disaster/recovery plan or just moving infrastructure closer to your users to reduce latency). The latency between regions has to be mitigated both on databases and on your app communications.

The attention points above pay-off. Once you have all set, the cloud can keep itself. Looking for alerts on CPU, memory, network, and other usages, and triggering self-healing actions will be part of its day.

Architecting for reliability

To increase your app reliability, I list two good strategies to apply:

  • On the infrastructure and the app level. Adding several layers of tests and health checks is the most basic action for reliability.
  • Architecting for multi-region. Using pilot-light (slower), passing by warm standby and active/active multi-region (faster) architecture solutions for failover and disaster/recovery plans are good approaches. The faster one (active/active) requires the same infrastructure to be deployed exactly the same in two regions. Also, an intelligent DNS routing rule has to be set.
  • Reducing risk with infrastructure deploy automation. Examples of services like CloudFormation (AWS), Resource Templates (MS), and Cloud Deployment (Google). It helps you to create a single point of infrastructure description to be used across multiple regions.

Architecture is a living subject, just like digital products are. Looking for scalability and reliability on the same environment will make you achieve a fast and reliable architecture.

Avoiding problems, Entrepeneurship, Practical examples

Expanding a company to another country: Language

April 7, 2020

In 2018 I started the biggest challenge I’ve ever faced in my career: expanding the company I work for to the most business mature country in the world, the United States. Two years are gone, and I want to start sharing the knowledge I have so far. Maybe I’ll shorten paths to people that will read these articles. Since my roles so far have gone primarily through sales activities, this is the sight I’ll be applying to these articles. And in this first one I’ll start talking about the most essential aspect I can ever think about this:

This article at a glance:

Poor communication skills lead to lack of trust between your team and prospects/partners/any other important stakeholder outside your company.

Cultural differences can create big issues because of how you understand phrases in each culture.

The language

Pff Guilherme, this is obvious. Yes, it is. And yet it’s underestimated.

A simple exploratory conversation

I attend several events during the year to showcase our services and products. At those fancy places, I have the chance to talk to many people. Once I’m there I interact with people from other countries doing the same I’m doing: selling and expanding their companies. In one of the events, I saw this guy. He was from Romania. I don’t know how to say “Hi” in Romanian, but I remember his accent was something close to Russian. Since he and his possible client were close to me I heard two or three sentences of the conversation:

  • Client: “(…) and do you think your team can deliver the POC within two weeks?”
  • Romanian guy: “Oh yes, about the POC, we will develop using part of the data you sent me and also the data we have from our research, like the trends for investing in 2020

The Romanian guy gave more details of the POC (Proof of Concept) instead of answering the question straight. I could notice at that time that he didn’t understand the question. He just got the acronym “POC” and started to say the first thing that came to his mind. It was not a bad intention. He didn’t want to dodge the question. He just didn’t understand. But yet…

Lack of trust

The main error here (and this is one that I’ve already committed also) is losing the opportunity to create trust with that other person. If the salesperson can’t understand what the client is asking, it’s impossible to trust that the rest of the company will do any better. And even if the rest of the company understands better, the handover from sales to the technical team will be already gone. And a problem will be created.

From my experience: it doesn’t matter if it’s a B2B relationship: people buy from people. If you can’t talk to somebody with the same eloquence you have talking to a friend in a bar about the most random subject, you have serious problems. You won’t be able to create trust simply because there will always be a doubt if you and your client are understanding each other 100% and as a consequence, being trustworthy.

Your eloquence will be needed when questions different from those you are expecting to come, get into the subject. And they will come. Describing a product or service you’ve been providing for years will be easy even in a different language. But what happens when you have to offer help amid Coronavirus situation?

Cultural differences

One simple example: In Brazil, if you finish a conversation with somebody saying “let’s talk about it next week”, it doesn’t really mean you want to talk about the subject next week. There’s just a possibility. It might happen or not. When you are on the states and say something like that, you both are automatically setting a real appointment. And you will necessarily catch up on the week after.

Another example: oriental cultures (my experience talks about just India and China) tend to never say “no”. Even when they want to say No, they will say “yes, but let’s take a look at more alternatives”. Many years ago I had one guy from India interviewing on a colleague on my team. After the interview, I called the sponsor and asked:

  • Me: “hey, so what did you think about John (person just interviewed)? Can we go ahead and set him to start working with your project?
  • The Indian client: “Yes. And I want to know more people from your team that we can evaluate”

I took John out of his project and told him to start working with the new client ASAP. When I called the client again to ask about John’s credentials the client asked me: “but what about the other people we were to interview?”. That gave me one of the biggest headaches I’ve ever had when managing people. John had already created a big expectation about the new client, was excited and also got a raise. After a few days, we solved it and John started to work with the new client indeed. But all the headache could’ve been prevented with just one more question from my side, knowing the style of communication of the other people, still during the same call of above:

  • The question that I should have asked: “So, Mr Client, actually will John start working with you guys right away or do you want to take a look at everybody and then deciding for the full team at once?”
Office, Practical examples

3 quick tips and more for managing a remote DEV team

March 31, 2020

Amid the Coronavirus reality we’ve been living since February, many remote work guides and best practices have emerged. In this article I hope to help the niche of software development teams and industries, sharing the experience I gathered over past years. The intention here is to start from scratch if you are not used to working remotely at all, but feel free to head straight to the point you may find yourself more interested in.

Tip 1: Training

Never underestimate the effectiveness of a training session before starting with a new methodology. It might look very simple for you to work remotely, but your team might see it differently than you. Not training is not an alternative just like stopping everybody for one week, putting them in a room with 8h/day of training, is not. If you are in a rush, grab the first morning you have and do some training. (This isn’t the focus of this article, but you will find some useful tips here, and here, and also some training tips here). Train on the go is the key to this quick turn. Since developing software is an activity that can easily be done anywhere, you probably won’t find many barriers with your team embracing it. But you do have to take care of productivity…

Tip 2: Pick the ceremonies

The quickest takeaway from this article: make daily meetings. I suggest even twice a day if the 100% remote work is new for you. You should use the daily meetings like they were described: 15 minutes of people saying what they did, what they will do, and what is blocking them. Pay extra attention to the blocks listed. If no one comes, ask some questions to stimulate them to come out. There are always blocks. The retrospectives might be challenging at first, but I know they can happen remotely. So give it more than a shot. The ceremonies, specifically the dailies will give you inputs about the team performance, which leads us to the next item…

Tip 3: Act

Be proactive. You must be an example of the posture you want to see on your team. Bad performance is easy to perceive in the daily checkpoints. Once you feel somebody is not producing as they could (that will happen) you must act and do it quickly (by producing I mean both performance and will to do the job). If you don’t, that will sound like a message for the whole team to slow down, because nobody cares.

This kind of action is not an inquisition. Have your mind clear of judgments about people and base your questions just on the facts you already know. (This article, from step 3 on will help you with these conversations). Always point out what happened and ask for an opinion. In 99% of cases people know they’re doing something different from what is expected. If the person doesn’t see anything wrong on what they did, you will have to show the consequences and then get to a common understanding. I do recommend you reach out to the article mentioned for further clarification about a feedback session.

Mindset: be always open and transparent

Having the same no-judgment mindset of the item above, be open to questions at this moment. Your team may be afraid of the changes not only on the work methodology, but also with the whole economic environment. If they have questions, prepare to spend more than just 5 minutes talking to them. They might want to talk about personal stuff before going to the real point. So keep your ears open and don’t moments of sharing thoughts about even your personal feelings about the moment. Keeping the routines of feedback you already have (or should have) is key to this moment. They are waiting for the right moment to ask you though questions, so be prepared to answer.

We all are under uncertainty and a new situation never faced before. If you are calm, your team will be calm. Always communicate to them in a simple way about every new step your company is taking to respond to the pandemic. Sharing information, even if they can’t vote on tough decisions, will make them feel part of the moment. You will also be reminded as someone who takes care of your people.

Career, Customers, Entrepeneurship, 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?

Digital transformation, Entrepeneurship, Innovation

The new companies of the digital society

February 10, 2020

We can clearly see a difference between traditional business models so present in the entire 20th century and new business models and products pushed by several startups since the beginning of the 21st century. In a world that doesn’t look like it’s slowing down, what will be the next revolution on investors’ and entrepreneurs’ mindsets?

Let’s compare the traditional and the new business models to understand the difference, and then compare to most recent movements that can give a tip about what’s to come.

20th century: the traditional business models

For this comparison, I’ll use the Gerdau (former Ameristeel) scenario. Gerdau is a company founded in 1901 which primarily works with the Iron and Steel commodities. They produce bars, beams, rebars, semi-finished, and value-added iron. They are also vital for the production of high-quality steel for ships, oil platforms, and cars.

Their business model is B2B. They don’t focus much on the end-user. Despite recent changes, they are not on the same wave of startups and disruptive business models. Related to social impact, they do have international seals of commitment to the environment.

Very straightforward: we can say they produce the best iron in the world. That’s it. They built an empire of $11 Bi with a single source of raw material that is present in all the continents.

Gerdau logo

21st century: the current Startup business models

In the past, we had big companies excelling at broad product offers. Nowadays there are many startups we see excelling at taking one single problem of our society and solving them.

We are in the experience era. There are startups pushing banks to digitalization. Also, startups pushing old business models like taxis and hotels. There are also startups putting just a layer of experience over existing products, and making a huge success.

Duolingomade learning another language something enjoyable, simple and gave autonomy to people who want to study. All of that through a different experience of learning.

Duolingo landing page

Nest has been doing good on residential automation/control. You remember this one below?

Old thermostat

It has plenty of information and sometimes is confusing. It shows current temperature, the temperature set, the fan speed, the modes(?) in use, and more. Honestly, I’m already lost just after listing these features.

New thermostat

Now check this one from Nest. It has a futuristic appeal, but it also made controlling the air conditioner temperature simpler. All you have to do is turn clock or anti-clockwise to adjust the temperature. Then the system does the rest. It also shows you the time windows when you are saving energy and learns from your habits.

In the past, successful companies were those with broad set of products and services. For the experience era, companies growing exponentially are those focusing on the experience. But what about the future?

3rd wave to come: the new companies of the digital society

Consumers are changing their demands. Millennials are reaching profitable ages. Because of that, they are pushing companies in some directions, and we must pay attention to it.

Also, millennials are native influencers. They influence and inform their families. Teenagers and even children may not have 10 friends, but they have 10 thousand followers on YouTube and Instagram.

The new consumers are people willing to stop buying from a brand and start buying from another based on how it positions itself to social causes. Nike’s Kaepernick is a good example of a brand that stood for a social cause. Even after stocks falling and fans boycott of known products, Nike was wise enough to release the manual “how to burn our products safely” below. Watch the original full ad for Nike and Kaepernick here (you can also find more details here).

How to burn our products safely

Nike (as seen above) is one example of companies standing for social causes. Tom’s with its former “buy one give one” is another good example. Johnson & Johnson is within the companies that donate more vaccines to causes in Africa. At last, Google has been using 100% of renewable energy on its data centers and offices since 2017.

For the third wave, it won’t be enough to have a broad set of services or products. Adding experience to them will be cool, but the experience will turn into a commodity as well eventually. The successful companies of the future will be those willing to stand for real social problems, both being supported by their fans and supporting them.

Do you see your company moving towards this direction? And how can you keep helping to turn the world into a better place?

Customers, Digital transformation, Entrepeneurship, Innovation, Practical examples

Don’t know where to start using design in your digital products? Here’s a suggestion

January 3, 2020

Design is one of the base investments for digital products in many industries (DMI 2015; Gartner 2018; McKinsey 2019). It should be used to foundations like understanding your customers and putting him at the center of your plans, and also on the other edge to help you find differentiators. As a continuation of the article from Jan 2019, this article describes some achievements some clients had during 2019 after a simple first step: mapping the user journey.

$150k savings with IVR

$150.000,00 yearly savings after micro changes to the IVR (Interactive Voice Response) of a bank. The exciting part here is that a very short user journey mapping process achieved it. It all started with the standard order to reduce costs on the chain. A UX Researcher was designated to make an evaluation of the entire set of channels used to communicate with the client.

During the first week of work, he noticed some reports on the IVR records shown that around 25% of calls redirected to a support position were regular questions like “what is my balance?”, “what is my pre-approved credit limit for a new car?” and “where is the closest branch in my neighborhood”? This scenario is one of the shortest journeys we can draw for a user: he just wanted to know his balance! The main pain point for the phone channel was that he was taking more than 2 minutes to do so. But there was also an opportunity to optimize costs.

The UX Researcher knew those topics should be answered without needing a human anymore. He delayed his initial researches and told the story to leadership. After a week of work, he and a developer were able to address two critical questions from clients on the IVR. They pulled questions that would be redirected to a human to answer down to the automatized services. 

Decreasing around 25% of the need for a human to attend a call at that time has been saving $150k/year.

15% more sales after remodeling one node in the supply chain

This one goes the other edge in the complexity of changes in the process after journey mapping. Client 2 produces heavy machinery for farmers. He found out that one of the pain points for them to upsell more was the bureaucracy of field representatives. The farmers wanted to buy from their upsell strategies. Those products were directly related to more productivity and more profit.

But the pain point was that the representatives were slow in crucial activities of the chain: purchase and delivery processes. The purchase and delivery used to depend on much manual work involving taking the machine to a different facility to receive the software upgrade.

As an output of the journey mapping, entirely new software is now working and replaced the many old ones. This new system allows the farmers to buy the upgrades way faster than before, just like in e-commerce.

The light start

As the examples above show, mapping the journey of your user is an exciting way to start using design thinking methodologies in your company. After mapping the journey, many other tools may come like: workshops, more research, data analysis, prototyping, drawing screens, etc.

Avoiding problems, Customers, Practical examples

Coding is the easy part

December 30, 2019

I realized I often tell this sentence whenever I’m internally coaching my colleagues in the company. But what does it really matter? Of course, coding is not easy, otherwise, anyone could do it. But what about the soft skills? As soon as you get more experience in a developer role, more responsibility comes. The new responsibility will pass through talking to other people for sure. This is when things start getting difficult.

Internal discussions/guidance

Let’s say you are a senior developer and is also one of the tech leaders in the company. You also want to help other people’s careers to evolve. Then you start helping to develop the junior guys on technical skills. This is simple: make them do hundreds of POCs, demos, exercises and etc, and have the concepts in mind. No matter how long it takes, it’d be easy to see if that person is making progress or not. It is zero or one. They either did or didn’t. Simple.

During the same path described above, you will notice some behavioral soft skills needed for that junior guy. I’ll try to help with some questions to ask yourself:

  • Do they behave properly in meetings?
  • Do they stand his point? But also be flexible to listen to other people’s opinions?
  • Do they listen to other people? Listening is more than hearing
  • Are they humble when talking about his accomplishments?
  • Are they humble when talking to other people?
  • Does the team like them? Is he a pal?
  • Do they stand like a person or do they easily compromise for almost anybody else’s opinion?
  • Are they open to discuss feedback?

External relations

In IT we are always providing service. Doesn’t matter if your clients are internal or external, you are providing a service. This is the most complicated and the one I see always as the source of problems in all projects.

Everything starts like a heaven relationship, but eventually, somebody will miss something in the process. The other part will try to help and will accumulate that load of work. The load will be like a pile and eventually will fall. These are the crisis we solve every day and those soft skills are so needed. Some questions to help thinking:

  • When talking to clients, does your mentee listen? 
  • Does he clearly know the boundaries of everybody’s work?
  • Does he understand how to tell people to do stuff without being arrogant? (Serious)
  • Does he think he’s better than the clients? (Serious)
  • Does he have a posture of helping people to solve problems instead of trying to be the center of everything?
  • Is he a problem solver or a procrastinator?
  • Can he understand the difference between problems, and solve those more important first no matter their size?

Process boundaries

For my experience managing several projects in many methodologies to develop software, I can tell that roles are often overlapped and misunderstood. It is someone’s responsibility to perform a task. Like in a volleyball game, if nobody puts the ball up, it will fall. Many balls falling and a new crisis arises.

Sometimes telling the other side they have to do something or they didn’t do something is the hardest part. But is also the most important. And in fact, the hardest part is bringing the problem, show the owners and how to fix it in a way it doesn’t occur again. But everything in a way that the final result will be a bonded relationship. On the time you give the news, arguments may happen and people might leave feeling bad. But once everybody cools down and recognize the good for the process and the final goal, since you passed the message in the right way (not being arrogant, not just throwing the problem to the other side but in fact bringing and discussing also the solution) people usually have the maturity to reunite and keep working together. Here are the questions for this topic, but now for both the mentor and the mentee:

  • Are you backing up your coachees/mentees when they have to have hard conversations?
  • Do you encourage them to have those moments?
  • Do they have the moments? Or do they run from it expecting you to solve their situations?
  • Do they prepare themselves for the moment prior to it?
  • Do they talk to people to get other opinions on how to deal with the hard moment before going for it?

All the items above are part of a developer regular work. They are very hard to develop and also take time. None of them are related to code.

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.

Practical examples

The 2 main challenges of managing a project 5.1 thousand miles distant

October 27, 2019

Recently I finished managing a project 5100 miles distant and all I can say is that I learned a lot. The team I managed directly had 9 people for some time and finished with 6. I’m sharing here two of the biggest challenges I faced during the project and how we overcame them.

1. Language

Part of the team, which lives in Porto Alegre, speaks Portuguese as their native language. We speak English as well, but it’s not the same as a native language. The rest of the team, speaking English, were 5.1 miles distant.

Portuguese is a broad language, and English is way more straight to the point. Also, culture and context make a difference. Using Portuguese, it’s natural to talk about a point without reaching the point itself (using passive voice). If you want to say no for something, you can say no without using the word “no”. This is one of the traps I fell inadvertently.

Sometimes I even realized a bit of an ego holding part of the team to ask questions. I could tell they were not 100% sure of what somebody told but they wouldn’t ask to make the information clearer. It’s something small, but all the points not understood 100% eventually had to be clarified and time was lost. Sometimes bad decisions were taken and rework was the consequence.

The language is a barrier. We cannot avoid it. Ideas and complex scenarios are tougher to explain.

2. Sense of lack of communication

During the project, I kept conducting regular ceremonies for communication, but I was always feeling a lack of communication. Sometimes I thought the team should have more autonomy to reach the client more often, without relying on me as a proxy (bad practice found here). We tried and started to improve. It did start to work from the 7th month on.

At the end of the project, we traveled to the client headquarters to validate the system faster than we were doing. This trip was crucial to creating a good relationship with the entire team. It decreased dependency on key stakeholders and it was easier to see each one’s potential.

What were the problems and how we overcame them

For practical activities, it’s hard to split the language and the lack of communication because they often seem to be the same. They are not. How did we overcome these two challenges were the most important part:

Language

Naturally, team skills in English improved. In just those few months of the project, it was not enough to have everybody’s English on the state of art. But we improved. The week we spent on the customer headquarters was also a divisor in terms of language. All the team got to understand better each other also considering the different cultures.

Communication

Status report

since we had a mix of waterfall and agile practices, the status reports were part of the plan. Few of them were sent. Many of them were missed. What makes me sad here is that they were missed. What makes me happy is that nobody missed them. They were just a group of information being discussed daily. Different formats of “status reports” could have been used. At the end of the project few short and summarised emails were used for the same intent. Both had the same impact.

Daily meetings

We started with daily meetings. They worked just in terms of high-level catch-up. The big mistake here was not having the business representatives on them. From the middle of the project on, the daily meetings were just a quick and superficial report of what people were doing. No one was actually taking care of the project using the daily meetings. From a business and practical standpoint, they could have stopped at some point and not much would have changed. Besides, they were important to create a team and a collaborative environment.

Emails

It’s unbelievable how easy it is to fall into the trap of sending an email and throwing an invisible package of things to solve to the other side of the wall. We made this mistake. And the team fixed it as soon as it realized the emails were actually creating friction instead of solving problems. We didn’t stop to send emails. But we stopped using them isolated and always had a quick catch up meeting parallels.

Bi-weekly demos

The demos happened always as planned. The good and bad part is that they created a lot of discussions about what was being delivered. They were bad because highlighted our lack of alignment in terms of business decisions many times. But they were also good because highlighted our lack of alignment in terms of business decisions many times. Then after the demos, the project used to have new turns to put the requirements back on trails.

By demand meetings

Every time we had meetings, we found solutions for the problems. No exceptions. Every time we got to talk, we solved problems. The meetings that started to happen after some business decisions lack of alignment were crucial for the project’s success. Here I’m talking about both long meetings to detail requirements and short meetings to synchronize small decisions.

I shared some of my key learnings in this project. I hope it helps you guys in similar scenarios to overcome your current project challenges.

Entrepeneurship, Innovation

UX is the new black

October 27, 2019

Annually, Gartner presents its most recent findings during the October event in Orlando. During a financial panel last week, the thing that impacted me the most was the UX topic being discussed in 2019 (actually just one year after being introduced) in a more than natural way. That sounded like “what are you doing in financial if you don’t have UX as a base in your strategy?”. The analyst didn’t even dive in to show more numbers and companies that adopted. It was so easy for the message to go out.

The event

Gartner introduced the big concept called “embrace the power of the AND”. In the same event, they present technology trends and industry standards for a selection of around 10 industries. In past years I’ve been attending this, which is the biggest gathering of IT executives in the entire world, and you can find some videos on this LinkedIn page with a few of the content shared.

UX subject

Just a recap about UX here: we are close to 2020 and just a few banks around the world actually invest and have UX as a key point of their strategy. Even inside Gartner, it’s something new. The UX subject appeared for the first time in Gartner’s agenda as one of the main topics for the event just in 2018.

This term and practice/focus started to get stronger and stronger on software recently. UX is all about understanding how your customer behaves, understanding his needs, trying to solve their issues as quickly as possible and give a memorable and delighting experience. It can’t cover just the software. A good experience floats over all the channels you interact with a brand. If you have to give them a call, the support must be delightful. Or using an app, same way. For physical interactions on the brand store (or branch for banks, or any other facility), also chatbots, and everything else must be remarkable.

Wasn’t that supposed to be basic?

But isn’t it basic? If a cosmetics company wants to release a new perfume… Don’t they go to the field, understand how people feel about the existing ones, what is their opinion, test, retest, discard something eventually, and then they launch. When a new toy is launched, doesn’t it goes under the same process? But what about software? Why do we still have initiatives, led by few heads inside companies that believe (for real) they already know everything their user needs and how to solve it?

Doesn’t it sound crazy to create a new product (software) without asking people at least what and how would they solve the problem before anything?

The analyst approached the UX subject in such a natural way that it made me feel good! He stimulated the thought of if you are in the financial industry is unacceptable to start any initiatives without looking for UX. Good! We are heading the right way. We will get there eventually! But what about the other industries? Their time will come. No doubts.