Browsing Category

Avoiding problems

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?”
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.

Avoiding problems, Practical examples

Software architecture to scale business

August 25, 2019

Software is present in every organization that wants to grow at some scale. The software helps the company’s employees to be more productive and to reduce manual and repetitive works. The software can have the best possible interface, turned 100% to people productiveness, but as a basic item, it must work when it must work. When vital software to an organization fails, the difference between regular software and good software is discovered. And here I talk about its architecture.

When the architecture makes the difference

To talk about this subject, I’ll cite two real cases of two clients in the media area. They are close to me and had their business growth held for some while due to bad quality software.

Please, no more load

The mentioned software was a portal to Brazillian population access to a known TV show. With that portal, people used to register themselves to be part of the TV shows, donate money for good causes, interact with their favorite characters, and some other activities. Under normal circumstances, the portal used to handle everything. But when one of its TV presenters mentioned something about the portal when they were live in national network, it was deadly. We just had to count time and few minutes after, the portal was down. It could be simple stuff like saying live “access our website for a chance of winning a prize”. Or “access our website to talk to the actress X”. And the problem that repeatedly happened, taking the portal down, was a technical problem related to its architecture. It was not prepared to receive so many access like it did in fact. In this example, we see a powerful trigger to an entire population being wasted because of a software malfunction. The population (customers) already convinced to look for something, was frustrated with the malfunction and lost interest automatically. The TV show image was affected negatively, and he failed at enhancing its brand, increasing its overall engaged public and eventually losing some revenue.

Let’s integrate!

The second example is about a scenario when the software was a big aggregator of information coming from many different sources. It was responsible for some important transactions related to the company invoices. It operated fine for many months after its first release. But when the database went over some load, it started to behave slower than it used to. Also, a big project or renewing the entire UI was undergoing. But it would be a big failure if something beautiful was released without actually working. The loading screens were too slow and were forcing the user to wait for many seconds for some feedback. The impact on business was quite relevant because the selling process for a few of their products was also affected.

Solutions and business relief

For both of the scenarios, a new architecture was implemented. The first one focused heavily on caching. The second focused on shortening the times to get information. But both passed by a deep architecture remodeling.

Nowadays the first one counts with millions of users reaching their portal to interact with the brand. They also count with a stable portal, which allows the decision-makers to make wiser decisions than when they were under pressure. The second was able to release the new UI, which enhanced the relationship with B2B demanding customers, and no more transactions are lost. Now the roadmap is welcome again.

Avoiding problems, Practical examples

4 Minimum artifacts for an IT cascade-agile project conduction

June 2, 2019

Whenever we are running an IT project, if we already have a deadline set before the start, no matter what, this project will turn into more a cascade than an agile conduction. Besides this status report, I’m listing the minimum artifacts to have a successful project being delivered.

The scope

The scope is basic. It is the base for everything to come. You will extract everything from the scope: the schedule itself, the pace you have to go to keep the schedule, and the team to reach everything. The key information that must be in scope are:

  • The requirement list;
  • The details of each requirement;
  • For who is that requirement applicable?
  • Who has validated the details?


  • The time estimates to reach that deliverable;
  • Who is needed to perform the technical part (strong dependencies only);

You don’t have to hold the fanciest document. You just have to hold a document that everybody involved can understand. I’m suggesting this document model.

The schedule

As soon as you have the scope, you will be able to start taking operational decisions. What are the restrictions you have for your schedule? What team is enough for you to reach the given deadline? Can you beat it earlier than planned? Always plan to finish the project before your schedule says, and keep some margin for the problems to come.

The key information that must be in your schedule is:

  • When will you deliver each requirement;

That’s enough. I strongly disagree with going anywhere beyond this point. Otherwise, the project manager will dive to an endless cycle of micro controlling everything. Issues will come with simple or complex documents. Go ahead and create your own model. List the requirement and the date to be delivered;

The status reports

The status report is a weapon and should be used wisely. It can be used to mark milestones for the project and also to create a sense of urgency for some scenarios. It is a powerful weapon. Do not avoid using it. Here you can find the model I’ve been evolving for years. Some of the key inputs:

  • What changed from last status report to this new one?
  • Who are the responsible people for taking decisions on this project? At least one on the delivery team and other on the client (internal or external) team;
  • Where are we in the schedule? Do use percentage here.
  • Major executive items (green/yellow/red) like scope, people and schedule;

Still in the status report. Always remember: if people are asking you for a status report, it means a huge problem. Not sending or wanting it, but the act of asking for it. If they ask for an email to get to know how the project is going on, it automatically means they are not involved as should be on the project. If the status report is green, everybody knows it. Or if the status report will have bad news, everybody must already be feeling the bad news.

The scope changes

Since you are running a cascade project, be prepared for scope changes. I haven’t seen a single project where they didn’t happen. When I hear a scope change, I know I’m walking the wrong way. But it makes me happy because I’ll have the opportunity to put things back on track before the end of the project. Keep track of all scope change requests coming from all the team involved. Make it very clear those already approved and those which won’t be pursued for any given reason. A scope change track document will have the following information:

  • The new requirement OR requirement changed;
  • The description of what’s changed;
  • What’s its impact over the schedule;
  • Is it included in the project or not?

You can use this model to track the changes. Once they are approved, they must be listed as a new requirement in your original scope document.


Few other activities will require you to have a kind of formalization. Using email for that is enough. Some of them will be:

  • Deliveries approval;
  • Changes approval on scope and schedule;
Avoiding problems, Entrepeneurship

Matching Lean mindset with good intention mindset for entrepeneurs

April 17, 2018

The discipline to apply the Lean mindset must be everywhere. Last saturday I got myself into a class where we were discussing project management tools and concerns, focusing on risks.

The Lean scenario

We had this construction project as example. Almost everybody was stating that the project could be consider successful if we deliver it inside the defined scope, schedule, cost and quality planned (as PMI states for years). It is very subjective, because it will lay on the understanding of success each one has. If your goal is just to make a check on your checklist, keep that above. But let’s explore an exception.

Consider yourself as the project manager. The point here is: if during this construction a plumb is broken and your project release toxic wastes in a nearby river? It would cause an environmental damage at least. Naturally fixing the plumb turns inside your project scope. But it’s not the same for all of the rest. It’s not your responsibility to create a workaround to fix the damages to the environment (seeding trees, cleaning the river, etc), neither to care about your company’s image regarding media and the society (marketing advertising, taking water to the affected communities, etc).

To explore that we started discussing if you, as a project manager should tell your organization’s owners about what happened and the subject got into the MCSW tool to help evaluating.

MCSW tool

Making a break, we argued about the MSCW tool when we were defining the risks also. It is a tool to classify the importance of the item you are handling. M stands for MUST, S stands for SHOULD, C stands for COULD and W for would. Clearly there’s not a Lean mindset applied to this tool. It should be just DO, and DON’T. It’s yes or no. You must or must not do something about a requirement, or a risk, or a situation. Discussing about the points in the middle will be waste of time.

The good will thought

Getting back to the plumb. It SHOULD be your concern, as a good project manager to tell, and I suggest, to help planning something to fix the environmental problem and your company’s brand’s image. The project management bible tells you shouldn’t get involved unless it turns your project scope. And here we have a difference between entrepeneurs and people who just work.

But for many times, the complete support to the organization needs may conflict with the Lean mindset. In this case, telling the problem to people is Lean. But getting involved in the resolution is not, unless it is added to your scope. This is the time when the entrepeneur has to have maturity to let the problem be treated by other people and get distance to focus in its real challenges. Otherwise getting involved in unplanned activities, will be faced as micro managing.

Keeping knowledge and good intention close to you

One important thing to explore after this fact occurs is the learned lessons here. Forget about creating a document, writing many pages of FCA (fact, cause, action) analysis, and throwing it to the repository. The most important thing is to make sure the right people understood what happened and what it caused. Because of that plumb broken, our stocks dropped 20% in six months, and that affect the employees there in the edge because we will loose many projects for our competitors due to uncertainty about our service quality. It may cause people leaving the company and knowledge being lost.

The most important thing after this things happen is to keep this kwowledge. For sure you, as the project manager, won’t ever again be discplicent about the soil analysis and researches because you will be concerned with environmental impacts. It’s a chain and everything is connected. From the very beginning, the environmental problem, to the labor force working there.

Avoiding problems, IT is business, Practical examples

5 big companies mistakes moving to cloud without a good plan

February 21, 2018

A lot was discussed, and still have been, about cloud journey. The worldwide big companies already have their strategy turned to cloud ever since the applications start being planned. Potentials of security, scalability, autonomy and many other related subjects are not approached on time of project discussion anymore. The cloud doesn’t generate doubts or lack of trust anymore. Once going to cloud is an old subject, beside the attention points already brought, I discuss here some errors I’ve already seen, as a way to support and contribute to new moves:


Face cloud as a side-need

The cloud is the main actor on applications. It’s very common to see companies starting their journey with simple backup or storage routines on cloud. This way they can start dismissing their own datacenters. It’s an important step, many times needed to show safety to a skeptical to changes board. But rollback, backup, disaster recovery, and many other routines, which used to be hard to implement to OPS teams, are now trivial to big cloud players. Using cloud having only this objective is to underestimate cloud’s potential.

Self-managed services have a very high level of automation on the points shown above. Get the benefits from processes automation, and don’t waste time and money researching, planning and implementing. The not self-managed services also have a lot of automation built-in. Backup, rollback and DR are now the basics.


Decision matrix negligence

The option for one or another cloud provider is something very important and for many times underestimated. Selecting a cloud provider is like a marriage and can bring troubled relations! I’ve seen companies trying to run away from its 10 or 20 years traumatic contracts with giants like Oracle or IBM, neglecting cloud decision matrix. They ended up signing new contracts leading to new 10 or 20 years contracts with provider X or Y.

Big players like Google, SAP, IBM and SAP allow a very high level of customization. Keep it in your mind during the decision. Those will allow to configure everything needed to a big application. They cover dependencies, integrations and relationships with other systems, specific engineering practices and etc. It’s also very common that complex applications can aggregate benefits from multi-cloud operations. As an instance: infrastructures that has lower prices on provider X can get benefits from FaaS Bigdata services from provider Y, which is faster treating large data volumes. This way one single application can be distributed over more than one cloud provider and also over more than one geographic region. It allows business objectives like cost saving, delay reduction and access to specific features from niche players.

Beside the big players, there are many niche providers of PaaS and FaaS. Digital Ocean, Heroku, Umbler and Elastichosts as instances, are useful for not so robust applications. Those platforms have high abstraction levels, and it cuts the development/operations team learning path.


Low knowledge of the potential of the chosen cloud

The savings that can be reached using cloud resources, like rollback, DR, backup (mentioned above), monitoring, alerts and automated actions, are very high. Consider it when executing your migration project!

Evaluate PaaS services to run applications or FaaS for network tasks, Machine Learning, deploy, tests and other. As an example, I’ve seen that every company that had software running over on premise infrastructure, ended up at sometime developing something to improve its deploy and testing tasks. It means that, if 10 companies developed similar software, costing 500h each, they would have spent 5000h creating almost equal software. Having services like CodeDeploy, Device Farm, Fastlane and Firebase, this kind of development is not needed anymore. Fast access to these services saves many development hours. It gives more speed to companies and it means they will be able to answer faster to their customer needs.


Low tracking on investment

Do not treat cloud budget as a black box. Track the investment via capable people and separate it by application/business/whatever making sense on that reality. This way true decisions will be taken, contracting or refusing some evaluated service. This is one more practice to prevent the “marriage” with a cloud provider get similar to those contracts of many years with Oracle, IBM and etc, which all big company try to run away nowadays. We have already made mistakes in the past. Let’s learn with them!


No updates

As an example, it’s still common for companies to invest amounts of money buying different mobile devices to test apps. Lack of knowledge about services that allow to automatize testing on those devices make that money to keep being wasted and the benefits of automation not reaching the development process.

With more and more niche competitors growing, the lack of updates to the responsible team can be a big problem. Not knowing good alternatives to current services forbids you to discover and use new benefits.

Avoiding problems, Customers, Office, Practical examples

How to avoid suicide applications

January 29, 2018

Having the experience of managing many projects in many different methodologies and different mixes of them, recently I could notice some attributes that happen in all of them to make it to be a suicide project to manage. By suicide I mean a project that will face issues and go down until it reach an unacceptable status, leading to a client loss, or something extreme like that.

The items below were identified as something common to all of managing styles, and if any of them is common to you or part of your routine, it’s time to change something. Some of them regard people relationship and some of them technical parts.


No QA environment

A project which has only a formal Production environment. The development is made by coders on their own machines. There is no QA (Quality Assurance) environment.

It looks crazy, right? But it still happens. Usually it happens when who is paying the bill doesn’t understand how catastrophic not having a Quality Assurance / Testing / Homologation can be. When it happens you are dealing with your luck day-by-day like the image above.

The QA environment must be, ideally, an exact copy of the production environment. Routines of copy from PRD (production) to QA must be maintained from time to time. When it happens, whenever a problem on PRD comes, it will be faster to track and simulate on QA. If it’s faster to simulate, it’s faster to find a solution and fix PRD. When production is fixed fast, the client loses less money related to that failure, or its brand is less affected due to that stop.

There can be different ways or minimum-requirements to at least have a trustworthy test before sending new code to PRD. The QA data can be different of PRD current. The environments may have different hardware configurations and etc. But the more differences QA and PRD have, the more time will be spent to track down issues.

Talking about a different service, when you don’t have a QA environment, holding proportions, it’s the same thing as a doctor trying a new surgery method without testing it on mice or monkeys before. It can work. But there is a huge chance of going wrong. And when it works, its nothing but luck.


Zero Automation

The more automation you have, the less human errors will happen. People will fail. And it’s normal! Let’s let people to think on what really matters and not on routine tasks. Somehow it will happen in someday:

  • They will commit the last code to the wrong branch. Then production will have a break;
  • They will forget to run a script before deploying a package. Then production will have a break;
  • They will forget to run minimum tests before running a new process or service. Then production will have a break;

A good way to prevent those errors to occur is to automatize as many things as you can.

A good starting point may be automatizing the deployment activity. Many companies I’ve already seen still have issues with deploy. They plan 4 weeks in advance for a deploy. The deploy is done. It crashes. It requires one or two weeks to fix the code and get production running back again. Then it plans with 2 months in advance. It crashes again. If the deploy is a problem, why not turning it into something trivial? Try to make it everyday. A lot of things will be learned.

Automatizing tests is also a great initiative. Automatized tests is one of the best weapons for software stability. The more coverage of tests your app has, the more stable it will be. These two suggestions will require time to be implemented, but their benefits will be felt on software credibility trough the whole company.

Talking about a different service, not having automation is like loading a warehouse box by box, without a fork-lift. A lot of time will be wasted of course. Also some of them will be dropped. Some of them will be shaken too much. It will work, but a lot of risks are added to the project without a need.


Key-user displicence

The one responsible for testing your project is the main actor of your routine. They will be whose opinion will be asked about on going practices. This person must be committed and addicted to your project, helping and pointing fingers to anything that goes wrong. The best projects I’ve ever been enrolled had very picky people testing and giving their OK to delivered features.

If your project lacks this concern, many problems may come up:

  • Lack of perception of value. What you have been practicing/telling is not what the customer likes to hear/watch;
  • Lack of alignment of what is developed versus what really adds value to the business;
  • The worst one: Lack of knowledge about the system. This person should be the one who knows all the system. If they don’t, many problems may come up because of different conceptions of why something was developed in some way;

This example is like a mom who doesn’t care about its baby education. It will grow, of course. But it can turn into a time bomb.


Low judgement at technologies choices

Technology is something serious and can’t be treated as a fashion trend. Fashion trends come and go and are renewed from time to time. A programming language, framework, feature, cloud provider neither anything related to development can be elected because its fancy or is the thing who everybody is talking about right now. All of this decisions must be questioned by the development team and, if possible, count on help from someone outside the project to think together with the team and reach the best choice.

When wrong technology choices are made, it may cause some problems like the following:

  • Difficulties to find people who know that technology to work with you in your project;
  • Problems in the future due to incompatibility of that technology with the project requirements;

Using the parallel to other services, using a new technology which is not proved yet is like buying a hamburguer with vegan-bacon inside it. It can be good, but is not proved yet. It will be your bet.


Deficient communication/status

How is structured your routine of communication with your client? Do you have formal moments to share information? Or do you make it when a trigger come? At this point there is no right answer, like suggested on the article “The magical answer for software development project management“.

But you will have a process to share information and to tell what you are doing to whoever is paying you. It can sound strange, but sharing this information may be a serious problem in many projects. You must ensure the activities you are conducting make sense to the client, and they understand that what you are doing is good to the business. Will you have a weekly meeting? A daily? A status report?

When you don’t have a process to give feedback on what you are doing, is like investing money with an investment company that doesn’t inform you about your gains.


Why to attack all of this?

All of the statements above refer to practices that must be figured in your project. Otherwise they will mean problems on the relationship or on the app data. Whenever any of them happen, they mean losing money or at least weakening the system owner’s brand. It may be natural that the main apps of a bank won’t have large issues. But the user doesn’t like when the registration to that cashback program crashes. It means the bank is not serious about their user and marketing advertising.

Avoiding problems, Practical examples

When and how to do a status report

January 15, 2018

Following a list of few articles already written here, one of the activities I consider very important and I enjoy the most is creating the “status report” for the things that depend on me. (This practical example, was created few weeks ago to a real project).


Status report are NOT only for projects!

Status report is a bigger thing, and doing status reports is not only for projects, but also for everything that depends on you. Few examples:

  • Telling your leader what, about that key activity to the company, advanced during the last week;
  • Telling people what you learned during that important event;
  • Letting people know how is your project going on (sure);
  • Managing your own team;
  • Let yourself know how your life plans are going on. It can be your tool for the self-retrospective moment;

Whether you want to send it to someone (like your leader eg), or not, the status report is a moment, where you have to stop everything and take a look at what really matters from above.


Creating your model

What do you want to report? As of many status reports I’ve already dealt with, probably the most basic information is: date (when it was generated), last updates (textual relevant things) and KPIs (executive numbers). You must also have in mind who will receive it (if your plan is to send it somehow). What is the language the people on the other side will understand? Should it be more executive? Can it be very detailed (probably not)? Below I’m showing some suggestions for some kind of reports as examples above:


Key activity status report

You can think on sending your information inside an email’s body, according to how small and/or important is your information. It depends on how formal you want to be.

  • Date – is the information inside an email? The email sent date can be your information. Otherwise, say when the snapshot was taken;
  • What is the activity? Whenever you look at it, it will help you to keep the focus on what really matters and to take away anything which is not aligned with your main goal. What’s the expected result?
  • Dependencies – suppliers dependencies and schedule are very important to show. Anything you depend on must be shown here, because it may affect your progress.
  • Updates – general relevant information. Example: during this week, activities X and Y were finished. The last one, Z, will be finished in two weeks. Also, the scope or important facts regarding an important activity changed.
  • News! – are you researching a new technology to the company? A good section could be news regarding that research, having its content coming from the top influencers.
  • KPIs – how can you measure how close you are to reach the activity’s goal?


Event results status report

So the company is investing sending you to an important event in your area. It makes sense to let everyone know what you learned there and sharing the new information with whoever wants it. Imagine it will be 4 days of event, then one compilation a day can be nice.

  • Date – what is the day inside the event?
  • What was the main subjects? What was the subjects you heard during the speeches? Did you know any new important technology? Who was there talking? Was this guy someone known widely? What is his LinkedIn profile?
  • Descriptions about everything – Be short but also say everything relevant that was spoke. How can you and your company get benefits from that speech? Can you suggest an strategy to move towards that opinion/techonology?
  • Opinions! Since you were there, give your opinion. The speech was nice but you have your doubts about the subject potential? Say it!


A regular project status report


Team progress status report

If you are a team leader, a status report can be very useful to have regular looks at your work as a leader. Let’s look how your team is doing! It will, for many times, get crossed by the regular project status report (above), but there are more things to look when we talk about team, not only projects.

  • Date – the date when was this snapshot taken;
  • Operation / regular activities – it’s basic. How are your regular activities going on? Create a quick KPI here: is everything ok or not? Are you up to the schedule with your regular deliveries? Extract it from the project’s status report suggested above;
  • Customer – how is your relationship with the customer? Do you know who is responsible for taking important decision inside it? Who are your key actors that you must monitore everything they say? What is their straight current opinion about your relationship right now? A satisfaction survey, conducted by someone new can, be very useful;
  • Team health – is everyone inside your team well satisfied with their job? How does it fits in their careers? It’s your job to ensure everybody is well motivated and feeling guts.
  • New stuff – how are your plans to improve? Why not showing plans for a new process you may be thinking to increase people’s knowledge? Also trying to reach someone new inside the customer you don’t have a established relationship yet? It’s time to look to whatever is important over all your responsibility and plan actions to improve them;


Next steps


When you must let people know about your status report, it’s meant to be presented, not just sent. The most important thing after a big status report, is getting feedback. The feedback will also come from yourself when you are updating your file, and not only from people who will receive it. So, whenever you find something not going well as planned, plan and take actions to put that thing back on track.

Avoiding problems, Career, Customers, Practical examples

Communication issues? Maybe it’s engagement issues

December 24, 2017

I started thinking on this article as my self year’s end retrospective. And I realized the biggest thing I learned during this year regards engagement.

I’ve been hearing, for years, that “80% of the projects that fail, fail because of poor communication”. That’s a sad true, but this year I realized this is an easy but messy abstraction. When you say that communication is the problem, you are hiding many serious problems, not only in your project, but also in your organization. And after that eureka moment, a new one came: people do “communicate the proper way” if they are engaged and have support to develop themselves.


Some examples
  1. We have a contract to watch an online app. It’s not very critical, but we still have SLAs to accomplish when it’s down. Then one issue comes and the person from OPS forgets to tell the customer, during the first 15 minutes, that he’s looking for a solution. Beyond that, he takes one more hour to solve the problem, than the 4h regularly expected. It will cause an argument during a meeting between the managers and everybody will finish the subject saying that they had a communication issue;
  2. We evolve a very critical solution, that deals with money, to a customer. Then the developer didn’t create the automatized test and the app breaks when goes to production. It will cause an argument during a meeting between the managers, and everybody will agree that the QA guy didn’t communicate properly to the DEV guy about the missing test.
  3. The project manager tells the project is delayed, but doesn’t tell how much it is. When something goes bad and someone ask for it, he defends himself saying he told about the delay, and had an interpretation issue because those who read didn’t understand the message he wanted to say. Then after that meeting, everybody will agree that he haven’t communicated the right way;


Why these things happen

What I learned during this year, regarding engagement, was to identify why these examples happened:

  1. The person from OPS team didn’t tell the customer he was working at the first 15 minutes, and forgot to tell he would take one more hour to solve the ticket, because he was not well empowered of its position. He doesn’t understands his position. If he forgets to tell the customer about the down time, the customer won’t be able tell the users. The users will start calling the call center, and it will generate an overhead on the call center team. So at least 10 people will have more work to do, forcing the company to pay for that extra hours, because of one missing news. The person from OPS wouldn’t have forgot to tell anyone needed if he truly understood the scenario.
  2. The second example has nothing to the QA. The responsibility affects the developer. He hadn’t created the test because he doesn’t know that every one hour of that system stopped, makes the customer to loose US$ 10.000,00. Nobody, when old, will want to tell stories to their children like “hey, once I stopped the production environment, and screwed many people’s life”. So the developer was negligent about the test because he is not well empowered of its responsibilities and capabilities.
  3. The project manager will is not to hide information. He gets paid, essentially, to keep people informed. When he waits one or two months to say the project is delayed for 2 months, he doesn’t think the people from project will be needed in a next one, and it will cause a loss on the company. Since people won’t be available, the original project’s budget won’t be enough, and the whole company will spend more money to hire new people to the next one.

So if you are inside any of these examples, think on the other side as your true friend. Would you let, any of these examples to happen, if you knew how deep it would affect them?


Solving the wrong way

It’s easy to put all these problems inside one basket and label them as communication issues. Then, our technical minds will think about processes to guarantee that:

  1. The tickets system automatically send and email telling the customer we’re working to solve the issue;
  2. We will create an integration between the task acceptance tool and the code repository to check if all the tasks have at least one test designed;
  3. The project manager will always present the status report having the customer on it’s side, so no information will be missed again;

The suggestions above are not wrong and shouldn’t be faced as something to be avoided. But they must be the last alternative. They are all mending to lack of people engagement.


Solving the right way: build together

People tend to be good. When you share the right way their responsibilities and how their activities affect each other, they will feel inside the group and will always try to help everybody. So why not asking each one of the actors of these examples how they would solve the problem? Present the problem, tell everything that happened because of their behavior. How to solve? This is the most difficult part. Probably the first thing coming from them won’t be the perfect solution or the solution you thought. Then it’s time for to show a better solution and check if it makes sense to those who will put it in practice. A mix of the ideias can be a good start.

And now we talk about people’s maturity to solve problems:

  • If they are junior people with good potential, just letting them to know their responsibilities can solve the problem. They have good intentions! They won’t forget to tell anybody the next time about what’s happening;
  • If they are overwhelmed, you will advice about looking for self management tools. And also will help them to focus on what is important and not getting overwhelmed again;
  • If you realize its needed, why not using one of the process solutions described above as the wrong way? Take care because if must make sense to everybody affected. It depends on people maturity to not feel pushed;


The main goal is to look for a mindset of empowering and networks, as described on the image below:


Always have next steps

Once I was invited to join a retrospective. The goal was to help a team with an external vision so they could improve their processes. The first thing I asked was where the “next steps” of the previous retrospective were. For my surprise they weren’t.

Always keep track of goals and results. It gives you sense of improvement, and if it doesn’t it will be clear to find where new mistakes were made. Have a periodic checkpoint with each one of the scenarios above until it fits a track where the problems don’t happen again.

After that, when you have the whole solution, you will be able to share your good practice to other teams around you:

  • What happened; Why happened; When happened;
  • What did you do to solve it, what were the first trials, and what actually solved it?
  • What did you learn from it? Next steps;