Browsing Category

Office

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.

Office

Benefits and issues of home office

March 31, 2019
home office desk

Working from home office is not big news. Since middle age small industries and factories used to be built on houses basements. Their owners and staff used to live in the upper levels, or even on the back side of the land. This formula worked until century XIX when industrial revolution and the machines came. They were much more efficient than manual processes and with that they took the workers to the factories.

The remote work model is very common due to some wide advantages:

  • Flexibility to the employee on working routines, allowing the employee to have breaks during his schedule, dedicating time to their personal needs and getting back to work when it’s fine again.
  • Savings for the company: less spent on the facilities, transport to the employees, cleaning services, etc.
  • Life quality for the whole company, regarding everything that may stress the employee whenever they are at heading to, at the, or leaving the office. It avoids wasting a lot of time on traffic every day, and allows them to exercise during more flexible times, feed themselves better, and enjoyning family.

But it also has some disadvantages:

  • Social isolation – that may be pointed in some cases even as a begining of a depression-related disease.
  • Many extra hours – than it would be if the work was done in the office.
  • Lack of support – many people may miss support from co-workers for many kinds of activities.
  • Harder career ascention – due to less contact to managers, the ascention plans can be frustrated if not well set.
  • Domestic costs rise – since the employee will spend more time at home, it will use more of its own resources to work.

What about when we have colleagues that stay in the office?

A very important group that is directly affected by the home office style, is the colleagues group that have to stay fisically at the company or were forbidden to work remotely by their job/project requirements. They are affected mainly on the interaction with other employees, having more difficulties to manage meetings and tasks. All the communications with the colleagues that are at home must be well programmed to compensate their fisical miss. The frustration may increase when the work load is bigger to the employee who is physically at the company. Even with that, he must fit the home office colleagues schedule, suffering interruptions during his work routine.

Those who work at the company, generally end up gathering more tasks to themselves: take notes for the team mates that are at home; meet customers and take them to the proper solutions without the colleagues; or just finishing daily tasks that may be easier for those who are at the office. They may also get more pressure from the leaders who step by the office to ask for some urgent tasks.

What now?

So why not give it a shot? It can be a home-run to you. The home office must be conducted by mature people on the organization, who understands its behavior, the benefits and its responsibilities. The work load and the dependency on other people must be considered as well. The work routine is something that must be reviewed frequently.

Digital transformation, Entrepeneurship, IT is business, Office, Practical examples

How did Netflix reach the nirvana of ownership?

May 15, 2018

Netflix doesn’t have a CTO (Chief Technical Officer). Having a CTO would be a symptom of centralization of technical decisions. On Netflix they have just a CPO (Chief Product Officer), which is the chief for their products. Products and IT are the same. Netflix also is one of the most innovative teams on technology and value purpose on world. But how did they reach this point? What took them there?

 

Profiles and responsibilities

They were born this way. It was a mindset simple to keep while they were a startup in 1997. But this thought have been kept during the years even with company’s growth.

With a set of benefits to their employees, which can be translated simply on freedom for them to take the actions they think are needed, Netflix shares their actions on management and responsibility in their speeches. The main concern of a manager is to hire the best people on world. The main concern of all the employees is to take the best possible decisions, having all the company’s context available to rely on. Subscribers numbers, revenues, all the areas budgets are part of the routine information that the managers share with their teams. Managers require their team members to enroll to competitor’s hiring process at least once a year to ensure they are getting the money they deserve. There is no knowledge management also. When an employee leaves the company, their projects die with him. There are no junior, plenum or senior levels.

 

No rules

Netflix avoids rules and processes because they believe that when you tell people how to act, their creativity is restricted and it makes them to stop thinking on how to add more value to the company. It has a cost. It is common for hiring positions to take more than 6 months to be filled, because they require complex hiring process and high levels of subjectivity.

Having some benefits examples like:

  • Vacation time undefined;
  • Maternity leave time undefined;
  • Technical subjects budget unlimited;
  • Hardware and software budget unlimited;
  • No work plan definition: once you get hired nobody will tell what you have to do. You create your own project, work, finishes, tests, and goes to the next. At this point your manager can help you taking the decision if you want.

This freedom goes through only one restriction: act like Netflix interests.

This way the company, which is proud of saying that hires only the best possible people for their positions, and that has more than 4000 employees, reached a level of ownership hard to compare. Each one is responsible for their projects and has autonomy to define if it is useful to the company or not.

 

What does it generates?

It generates an incredible freedom environment for people to produce what they consider important. Once all the employees are the best in their areas, it is understood that they will have enough knowledge to take the best decisions. It generates more than 100 projects going on simultaneously from all company’s areas and being tested at every moment. IT projects can’t take more than 2 months to be finished. Each 2h one publication to production environment is made, and nothing is activated before going through A/B testing.

The great objective of ownership also is achieved because all of these conditions also have the intention to delegate power. Every Netflix employee must be capable of taking decisions without depending on endless validation processes or unnecessary opinions. Mixing freedom, responsibility and power is how Netflix reached and keeps his very high level of ownership among their employees and keeps being one of the most innovative companies since the moment it was created.

 

The model and how to learn with it

Compared to other companies on different acting areas, among the most traditional ones like industries and the most recent startups, Netflix reached his ownership through the joint of some things: almost unrestricted power, almost unrestricted freedom and seniority/maturity as a premisse.

This is a unique model that should not be pursued blindly, but used as inspiration to watch the disruptive way they found to manage their company

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.

Digital transformation, IT is business, Office

A vision about IT evolution

January 7, 2018

When the IT and the modernization it brought first started arriving the industries, there on the 1960’s, it was faced as something not wanted, but needed. The IT had its own language and terms, like the other areas, but for some reason it was not serious as the other areas. The IT people used to be treated as the people who could make magic and make people’s work easier. But what we have seen lately is a huge evolution and change on how IT is faced.

 

First scenarios

I heard during my graduation, from a professor, the conclusion that IT is a support area only. And I agree it used to be treated like that. The IT team were the strange guys, their workplaces were the worst, even not having windows to look outside. And it can be the reality until today for some companies. But it’s changing fast.

Old IT department

As a software service company employee, for years I used to be called to talk to our clients about new projects. The final conclusion is that all of those meetings were the same. I was called to create something new that could make activities easier and faster to be done by someone. And after that a waterfall move used to happen: less time was needed, then less people were needed, then less money were spent to keep that process/department.

As an instance, for those projects the procedure inside the demanding companies were the same:

  • Identify the need: we are slow at creating contracts for our clients;
  • Start the strategy move to change: let’s automatize the contract parts, that can be automatized, and add collaboration so our writers can work faster and together;
  • Call the IT department: hey, we want a tool!
  • Reach the ROI: we will save US$ 50.000,00 a year having less people writing, and reaching less our law guys;
  • Then the IT department calls the consultancy company (me): please build this tool.

After the tool was delivered, the contracts area got faster, the company saved money, and the whole IT talking was finished. Talking business, our clients were demanding about improving and automatizing parts of processes. The IT used to be faced as the support area which could solve problems or improve processes of the products areas.

 

Then the digital transformation

 

The customer experience focus, is pushing one of the most mature steps of digital transformation we have this far. The IT becoming the companies’ core. This move has been happening based on a world connected to the internet. Since everybody has a smartphone, and everybody want to solve things faster, leaving behind unnecessary stuff (like lines, support waiting times, etc), the IT is the way to reach those people. The customer needs are changing faster and the time spent on that formal process can’t be handled anymore. It must be possible to make changes and adapt at the same speed of the market. Because of that, the IT must be available 100% of the time.

Using the same instance, but now changing to mature business, the new procedure to improve something would be:

  • Identify the need: we must create a new feature to our final customer;
  • Start the strategy move to change: let’s include the feature inside the app;
  • Reach the ROI: we will make US$ 50.000,00 a year with that new feature;
  • Then let’s do it; No more boring meetings are needed;

With this core move, the IT is getting more importance on the business scenario. It’s not the ugly son anymore. The financial industry in Brazil is one of the most mature industries in world, and is pushing the others. I have already seen arguments between the final product areas, which used to rule the scenario, and the IT. It doesn’t make sense anymore to keep these two areas separated.

 

The next industries

This move seen in the financial area, which goes through every single company, isn’t common to all industries yet. For the next industries affected, its easy to understand the more B2C the company is, the faster will be its rush to adapt. Retail is a good candidate to be the next one. But what about the rest? When the factories will get to it?

Office, Practical examples

Status report – Um exemplo e modelo real

January 1, 2018

Status report é uma ferramenta poderosa para vários assuntos e intenções. Este exemplo prático traz um cenário real criado por mim algumas semanas atrás e mostra uma abordagem para passar a mensagem às pessoas que importam.

O modelo está apresentado, e todas as seções também estão descritas abaixo, mostrando qual é a intenção e porque faz sentido a este cenário. O documento está DISPONÍVEL AQUI (inglês e português) e você pode utilizar em seus projetos livremente.

O modelo

Identificação, gerente de projeto, objetivo e data

Estas quatro seções são muito importantes para garantir que todos que abram seu arquivo saibam exatamente sobre que projeto você está falando.

  • Cliente X – Qual é a empresa pagando e interessada pelo seu projeto? É importante para você e para qualquer pessoa dentro da sua empresa entender;
  • Projeto Y – Qual é o nome do projeto? Esta é a identificação para qualquer um que receba este arquivo entender seu propósito;
  • Gerente de projetos – Quem é o responsável por este projeto? Em todas as pontas que importam a você. Neste caso apenas minha companhia e o cliente foram importantes. Você pode adicionar outros fornecedores por exemplo;
  • Objetivo – Seu objetivo principal. É importante para manter o foco. Uma vez que este arquivo é acessível a todos do projeto, todos precisam entender a que eles estão contribuindo e se sentir parte daquilo;
  • Data – mostra o período a que o arquivo se refere. Mantenha histórico dos seus status reports! Isto permitirá que você acompanhe seu progresso, as coisas que você já tentou ou está tentando, e como elas estão indo;
Status, logos and datas planejadas
  • O status geral é uma informação executiva e para onde todos olharão. É uma mensagem simples mostrando como seu projeto está indo. Não se trata de como você acha que está indo. Você precisa ter números para definir. Neste documento foram usados 3 KPIs (mostrados abaixo) e as regras foram: se todos estiverem verdes, o geral é verde. Se pelo menos um estiver amarelo, amarelo é o geral. Se qualquer um estiver vermelho, todo o projeto está vermelho;
  • Os logos (seu e do seu cliente) possuem uma mensagem importante sobre a parceria responsável por conduzir este projeto. Isto passa uma mensagem subjetiva mostrando a todo o time como as duas companhias estão engajadas para alcançar o mesmo objetivo;
  • A data fim original é a primeira data planejada para finalizar o projeto de acordo com o cronograma;
  • A data fim replanejada é preenchida somente se você precisou replanejar sua data de finalização por alguma razão. As razões precisam ser mostradas nas atualizações (exemplos abaixo) quando um replanejamento acontecer;
Riscos, mudanças e dependências

Qualquer acontecimento aos riscos e mudanças precisam ser verificados por você, como gerente de projetos responsável, para entender se requererão qualquer tipo de replanejamento. Pode afetar seu cronograma, seus custos, pessoas envolvidas, recursos externos, fornecedores, etc;

  • Riscos é onde você lista tudo que pode afetar seu projeto e mudar algo planejado. É comum que seja algo fora de seu controle, então tenha um plano para cada um dos riscos para lidar com problemas quando algo der errado;
  • Mudanças precisam ser preenchidas quando algo relevante acordado foi alterado por alguma razão. Uma decisão foi repensada? Faça com que todos saibam;
  • Dependências é uma seção usada quando você tem tarefas dependendo do esforço de outras pessoas ou times. É muito importante pois se eles se atrasam, você precisará tratar o impacto;

O exemplo possui uma dependência com um deadline tachado. O objetivo é mostrar que uma entrega planejada não foi finalizada e precisou ser replanejada.

Também há uma dependência com um deadline pintado em vermelho. Isto se refere a uma tarefa que precisa ser desenvolvida por alguém fora do time original do projeto. Precisa haver uma pessoa responsável e também uma data quando o entregável será de fato entregue. Se a tarefa está atrasada, todo o projeto poderá ser atrasado.

Atualizações

Esta seção é a que terá maior quantidade de informações sendo mudadas de semana para semana. Todo seu conteúdo pode ser mudado de uma semana para outra. Aqui é onde você listará tudo o que aconteceu, pessoas adicionadas, resultados de testes, entregas de outros fornecedores e etc. Também gosto de manter dois sub-tópicos: o que foi finalizado durante a última semana, e o que será feito na próxima.

Cronograma

O cronograma faz sentido quando você está lidando com um projeto com escopo fechado ou não. Você pode usar para dar visibilidade sobre a próxima entrega importante quando estiver gerenciando projetos ágeis, por exemplo. Você pode mostrar atividades macro ou ainda mostrar 100% de todo seu planejamento (como o exemplo mostra).

O exemplo lista as tarefas e as dá cores:

  • Quando verde, está pronto para ser desenvolvido;
  • Se está laranja, depende de algo externo e não pode ser iniciado no momento;
  • Para vermelho, significa que está atrasado por alguma razão;

Também mostra as tarefas planejadas para serem entregues durante a semana (destacada em laranja na primeira linha da tabela). Estão representadas pelo X na célula respectiva. E por último mostra o percentual de cada uma das tarefas;

KPIs

As métricas que você decide medir durante o projeto. Para este, pessoas, escopo e datas eram os aspectos principais. A tabela mostra a métrica e o status de cada uma. Quando você tiver algo diferente de verde, você deve escrever o motivo que justifica aquela métrica não estar indo bem. Não esqueça de adicionar os custos à seção de KPIs;

Avoiding problems, Customers, Office

The magical answer for software development project management

December 3, 2017

Lately I’ve been negotiating with a lot of different clients about many different projects. Having a quick look at the projects, it’s incredible how people wrongly seek for one single project management methodology to rule them all. Beside that, when clients look for “agile methodologies”, what the biggest part of them want to say is: “let’s use Scrum for everything”. Then after my opinion was asked by a friend who was meant to establish a PMO, I had the ideia of this article.

 

Different clients have different needs

In my scenario, as a consulting company, it’s very clear to notice that different clients will have different needs. It’s common to be asked about software development methodologies. The main thing is that, even inside the same company, which is not a consulting as instance, there will be different ways to manage projects. There is not a single pattern. It depends on people. It depends straight on the teams maturity to act, and I will show few examples based on the infographic “Software development maturity evolution brief story“.

The traditional / waterfall / CMMI approach:

Yet the most common on big organizations. It gives executive information to managers and a lot of very concrete information about the project. It focuses a lot on process and files to keep track of everything that is happening on the project. Dependency mapping, communication mapping, scope controlling, and many others will be done by the manager. This will cost a lot of money.

The Scrum approach:

More flexibility, less process, but still some issues. Scrum will allow the project to be more dynamic due to less focus on processes and files. What Scrum says is “keep sending work and we will keep delivering it”. It has many good things: less time spent on bureaucracy, “customer first” mindset, etc. But it shows few problems: it’s hard to work with deadlines and dependencies, and dailies can easily lose the value.

The XP practices:

Flexible, focus on finding value fast, feedback at every corner. XP focuses on finding value as fast as possible with the MVP (Minimum Viable Product) mindset. It also helps to improve the team practices constantly due to it’s cycles of constant feedback. XP needs a very disciplined team to run with, otherwise they can easily loose the focus due to the lack of practices to controlling.

The DevOps approach:

Self-service, no bottlenecks and automation. DevOps has been the most-said IT word for the last year at least, but very few people can actually practice it. It focuses on bringing everybody that matters to the project to work together, and that includes business people, UX people, DEV and OPS people, and everything else that matters. They must have autonomy to take decisions. Nobody can be a bottleneck. The developers must have the self-service mindset, otherwise they will depend on others to finish their jobs. DevOps also bring some challenges, as the DEVs not enjoying to do OPS tasks, and OPS guys not enjoying to code.

 

Different mindsets for project management

All of the models above were explored with the benefits and the problems they bring. Each of them can be useful if applied in the right context. So, no one of them is the magical answer to whatever are the problems you may be facing in your project(s). The perfect scenario is to mix things up, EXPERIMENT, until you find the best model for you and your team. But how to do that? If your moment is not allowing you to find that now, you probably are overwhelmed by the operation and are forgetting to think on your real goals. Try to look things from above. Your main goals, on software development, are shown above, and there’s where your effort must be focused:

  • Deliver value constantly – changing the application background color from blue to red may be nice. But does it really adds value to the business? Will it make the difference to the project or to the final user? Focus on what really matters and not only on creating more code.
  • Customer first – the reason for every software project to exist is the end user. Always aim to please that team. If their opinion is not green about what you are delivering, they won’t use it. And your project will be useless. Is your end-user happy? Do they feel like the software has good user experience? Do they find value on using your tool?
  • Experimentation – the fastest way to improve things, even when you don’t know what to improve. Experimenting after a good retrospective is something to do very often.
  • Focus on people – the key to reach all the dots above. If people are happy and find value on your organization, trust you and like their environment and routines, they will be very likely to do and test everything the team may bring up.

 

Then manage your own way

So the answer for you to apply the best development practices to your projects is your mindset. Once your mindset is aligned with the goals you must reach, forgetting all process addictions, then your right process will be created naturally by the team.

Avoiding problems, Customers, Office

Communication – how

November 16, 2017

Lately I’ve seen many people getting stuck with problems to pass away the message they want to. It’s always been a truth. But since there’s too many examples that I could see lately, I decided to give priority to this article idea.

The main problem of the biggest part of people I know have, is the lack of context and how they structure an idea. It doesn’t matter whether they are giving a speech, talking to someone, or writing an email the problem is the same. We all know that communication has been the main cause for projects failure. This is SO REAL that it’s very easy to find good quality content being published frequently. One good example is this article from CIO which published an article giving some advice about common mistakes. Number 1 and 5 regard communication.

 

Richness of each interaction

From best to worst:

  • Face-to-face conversation: you can say your stuff and check if the other side got it, and get a feedback on real time.
  • Video conference: same as above, but with less clarity on the other side perceptions and reactions.
  • Telephone: same as above, but you can’t see people’s body and face reactions.
  • Email: you can write, but you won’t get a feedback (at least not real time).
  • Broadcast communication (videos, folders, etc): it will be very hard for you to get a feedback.

 

When you are talking to someone

First of all, the what is important, but it’s all about how it’s done.

Whenever you want to talk to someone, what your mouth says is less than 10% of your message. 38% is said by your face, and 55% by your body.

So if you are talking to someone and that is important, of course you must prepare your speech. Do you need to convince a customer that your decision is better than theirs? Let’s try to organize it according to the three steps above shown:

Your actual speech

Prepare A LOT. The more you get prepared, the easier will be to accomplish the next two things. Let’s say you are having a technical discussion: try to look by everyone else’s optics to be sure that all opinions were considered. Try to be the devil part and imagine the questions that may appear from the pickiest person you know. Do you have a colleague or a boss that always question everybody about everything? Maybe this guys can be useful. So, the most important part is to prepare yourself as much as you can, because if you know everything about that scenario you will be very comfortable to argue about the subject.

Your face

Now that you know everything that must be said, it’s time to be confident. People are more likely to believe in a message from someone they judge trustworthy. You don’t like to be approached by a beggar, right? Your appearance count many points here. Also, if you are showing happiness in your face, you will get people’s empathy easier. But take care and don’t laugh for everything, people can think you are making jokes on work time.

Your body

As above, the main thing is that people believe in what they can see. So you are your image, not your thoughts. Your body must be confident at the same time your message is clear and your face is calm. Worst time for leg shaking, to nail, to keep look at everyone’s face to check if they are approving or not. How to be that confident? Preparing yourself A LOT. Since you already are well contextualized with the subject, and your face is calm, focus on being clear and be confident.

 

Writing communications

Ok, you couldn’t find the person you wanted to ask or say something and will have to use an asynchronous communication way. Let’s make it VERY clear. You just CAN NOT send an important message by email and assume the other side got it and read it exactly the same way you wrote it. It’s never gonna happen.

But let’s say you want to send a report which is really bad for your customer. It must be formal (using email), but it also must be said very clearly. The perfect way to do is: write the email, check it a bunch of times, then find a way to call the person on the other side. Then TELL him the whole email, check for his feedback, change anything that he may disagree (according to the reality of course), and then you send it.

But how to write that email?
  • What’s the purpose? What do you want to happen after when the other side read this email?
  • Who will receive it? Think of you, being they, and reading it. What they will think of each sentence?
  • Use short sentences. People are lazy. Don’t write big paragraphs. They will stop thinking at the middle of the big one, and won’t get the rest of the message.
  • Hard words: avoid them. People know you are smart. People are lazy.
  • Don’t assume people know everything: it’s you who have all the context for that email. Everybody must be on the same page. If you are in doubt, explain.
  • Be clear: split your thoughts like below.
    • Introduction: I’m here to talk about challenge X.
    • Justification: we should talk about challenge X because of Y.
    • Argumentation: show your point.
    • Conclusion: what to do next?

Remember: you are not writing a book. Each one of the points above can be done in one sentence, as instance, except the argumentation.