Tips

The following are just some ‘tips’ that helped me (and most of them are still helping me) in my professional career. They don’t pretend to be an exhaustive list nor absolute truths relevant to any situation and context. Also I don’t pretend to get credit as the ‘creator’ of these techniques, some (maybe most) of them could sound like just common sense for a lot of people. It is just a small compilation from mentors I was lucky to have throughout my career, articles or blog posts or even tweets that since several years ago I was particularly interested in and of course personal experience. We can maybe even don’t agree in some of them and that is fine, maybe in the comments section we can start a respectful conversation and in my case discover other points of view

After that big but I think necessary disclaimer let start in no particular order

Who should read this? I’m passionate about software, team development and user impact. I started my career as a developer, a single contributor to different projects. My career led me to a management position. I like to think anyone in one of these positions or career stage could find this useful

Zip file and an unnecessary late feedback

A short story, several years ago when we were just beginning our career in IT. My girlfriend was doing small jobs as a ‘webmaster’, her client sent her a new job with an attached zip file by email. She just saw it and left it in the inbox for later. When it was definitely time to give an answer and show progress, she opened the mail, downloaded the zip but could not open it: ‘corrupted file’. She had to send an email basically confessing that in all this time she had not even tried to open the file

I don’t know why that stuck in my mind

When we are assigned a task we should quickly check that we have the necessary information and access to be able to execute it and give immediate feedback if not. Especially if we do not plan to execute the task immediately

Immediate feedback is invaluable or in the other hand, late feedback on an easy to confirm totally blocker situation could be very counterproductive

Keep the flow

A Manager years ago told us often “the ball is on fire, you shouldn’t keep it, you should pass it”

Taken to the limit can be dangerous. But an interpretation is that we should keep the flow, if our answer or work will take (let’s say) less than ten minutes and that will enable another person or team to continue the work we should probably do it now, don’t schedule it, don’t add it to your calendar or todo list. Execute it

Sometimes is answer an email or a group conversation if this allow other teams to continue his part on the pipeline we should consider reserve some time in the short term instead of for example hold the task and give an answer at the end of the day producing a one day delay on the overall result as the next team or person in the pipeline will most probably take it the next business day

This is particularly important if you are interested in the outcome. If you are interested in the completion of a task or goal why should you put yourself in a blocker or holding position?

Close communication circles

What is a communication circle? here some examples:

1. we ask someone specific information
2. a person give us that information
3. we thank

another example:

1. someone informs us about an issue
2. we fix it
3. the person who inform the issue confirms the fix

Sounds like just common sense, no need to write or mention this. Yes but in practice and in my experience it is not so trivial

Also another detail, we need to pay attention to the source and people involved in the communication. For example if the thread started as an email with a lot of people involved, then favoring efficiency switched to a slack conversation or a quick meeting with a small set of the original people it is almost always a good idea to communicate the agreed definition to the original thread (email in this example) so all the initial people are in the same page, we ‘close the communication cycle’

In some cases we are not responsible to close the cycle, for example we develop a fix to a reported issue, we inform about it but not get confirmation. Sometimes no-news is good-news but we can always try to force an answer by friendly explicitly asking for a confirmation about the fix in this example

Sharpen your tools

Like in different level with several or most of the tips included in this list, this is basically a personal opinion

In my opinion we are responsible for our work tools. Keeping them in good shape and ready to work. Be that a hammer, a car or in my case a laptop or a smartphone

In that context and in different situations it is difficult for me to understand or justify IT people who complain because the computer ‘is slow’ or something does not work

As almost in every case there are exceptions. But there is also several times when the solution is at hand, you most probably don’t need 60 open tabs in chrome or 5 instances of your IDE minimized for a week, etc

Changing your laptop or the latest M1 chip isn’t the only solution. You just need to use your IT knowledge to tune up and take the most of your current tools

Emails

Lately it seems that people get busier and busier

In that context if you like to write large verbatim emails explaining a topic or presenting an initiative you could be potentially missing readers every day

There are always exceptions and in some cases your audience expect a good explanation with maybe link to documents with even more details

But in most cases I found it effective to use a template similar to the next one:

• greeting
• quickly explain issue or situation that needs an action
• action

greeting: It could be just Hello or Hi [name] or if you get to know the person it could be something more lengthy and also informal. It is important in my opinion to correctly greet people, avoid start directly with the message or action or just mentioning the Name of the person, some people (like me) find it nearly rude

quickly explain issue or situation that needs an action: the issue, what needs to be done or in some cases context for a specific question or action

action: also very important, otherwise it could be interpreted as an email to inform something (like an anomaly situation). It is also very important if it is possible to explicitly point the action to a defined person or group. Otherwise you could end in the situation where when many are responsible none specifically is

Also it is more effective to present one topic at a time. If sending different emails, one for each topic seems counterproductive, a suggestion is to state each topic with numbered bullets so that it is easier to track each one, their response and pending topics. Avoiding, for example, that we send three topics, only one is answered and implicitly there does not seem to be an action pending from the receiver

Latency

A definition: Latency – The time taken for a packet to be transferred across a network. You can measure this as one-way to its destination or as a round trip

Translated to project communication, low latency could be very valuable, for example if a client or someone informs us about an issue in the core business of our team. We should give a quick answer with at least an ‘ack’. If we can give a more complete answer in lets say 5-10 min, ideally with the fix (following our example of the communication of an issue) we can wait for this more complete and valuable response. Otherwise we should quickly answer with an ‘ack’ “thank you, we are reviewing it.. keep you posted on this same thread.. or other personal, not automated answer” giving some time to the team or us to review and answer with the communication of the fix or with collected information that will add value to the topic

Sometimes the ‘ack’ response also includes a question, for specific information that will help us troubleshoot

Don’t forget to close the communication cycle and avoid going silence until we have a final solution or definition which can take time and generate a wrong feeling of ‘we are not doing anything’ or ‘this is not important to us’

Slack vs Email

Slack (MS Teams, Skype, any IM application) is very effective for quick communication. But when it comes to commitments I find the old email more effective easy to find and follow up

They are all tools, we should evaluate which is best to the task at hand

For example if you evaluate a weak commitment on a task that you are particularly interested in. Maybe is a good idea to put it written in an email that is easier (maybe days or weeks later depending on the task and commitment) to send a reminder and put on top of inbox again, a friendly reminder of the topic or also add more people to the thread

Fire & Forget

In my experience, Fire & Forget does not work in the vast majority of cases

If we are interested or specially if we are the owner/responsible of a topic or initiative, we definitely have to follow up. Either remembering about an email and putting it back on top of the inbox, pinging people, scheduling follow up meetings, etc

If, for example, we sent an email two weeks ago with no response yet. The reading is that we tried the ‘fire & forget’ and it didn’t work, we are not guilty of a crime but the responsibility is ours. We cannot demand or be outraged because the topic did not advance or no one took ownership

Know the core of your business

Several years ago I remember the CTO of the company I worked for at that time repeated to all the developers ‘Don’t get in love with technology’. I think he was referring to avoid always chasing the latest trend, the latest framework or programming language or having the latest hardware

My interpretation some years later was that in most cases technology does not exist by itself. It is accompanied by a business that gives it more meaning, like solving real people problems. In that context technology is a powerful tool

We can target to build a POC to for example test a new technology but always looking for ways to improve our current solution or looking for new opportunities, features, new ways to add value. Otherwise we are just ‘testing’ new technologies but building nothing or looking to work with the latest hardware to do the same work we are perfectly doing with our current hardware

Knowing the core of the business of your area or team, the core goal or responsibility will help you understand priorities: what can wait, what cannot and help you fulfill expectations in a more efficient way

Sometimes this is also not related to effort, for example a full migration of the solution to the latest tool/library/framework version. That could involve a lot of work from the team, maybe adapting the code and rewriting some parts, fixing broken unit tests, integration tests, etc. When maybe a new feature over the current solution will add more value and is ‘cheaper’ in terms of effort

Sometimes a full migration is mandatory because for example we are at the end of support of a critical component we rely on, sometimes it pays off in the long term, sometimes we are targeting team motivation. It is a matter of balance, in most cases we all like to work with the latest technology but we also like to reach goals, have impact and not always they are closely related

Know your limits

I think it is safe to say I seek to give 100% or I’m giving 100%. I mean most people probably will agree that say or target give 100% in our work is correct

On the other hand it is impossible to maintain a 100% rate all the time, at least in a healthy way. Know your limits, register when you are at a higher demand rate. Make it an exception, make it explicitly known by you and the team. We are making this extra effort to meet goal X for example

Trying to keep the extra effort as rule instead of the exception in you or the team will most probably produce exhaustion at some point of time, a potential team low performance peak as a consequence and even to be the cause of team exits

At the end of the day and in several situations in a goal oriented environment if you don’t meet expectations and you are giving 100%, this last part surely matters but probably not enough

This is a marathon with few identified and justified quick races in the middle

Understand the requirement

credits: https://xkcd.com/974/

Sometimes you just need to ‘pass the salt’ nothing more, nothing else

Other times it is true the system will help save time in the long run. In those cases you most probably need to pass the salt, give a quick response and then work on the system for future requirements. Two priorities here

Priorities

There will always be priorities and urgencies. Our backlog is infinite we should work according to priorities and keep them updated

Force a reevaluation of priorities continuously. If you for example are working on a task and in the execution of that task you found new paths not originally estimated. You can ask yourself if these new paths have the same priority, if not you can even include them in the backlog for future prioritization. In any case avoid delaying a priority task because you found related lower priority tasks that need to be done but not immediately

Related to this and in the context of an issue a quick workaround that mitigates an issue now is usually more valuable than a final solution hours later. Following the example you can work on the workaround, give a quick response and then work on the final solution

Quantify

If we have data, let’s look at data. If all we have are opinions, let’s go with mine. –Jim Barksdale

Most of the time we have the tools to give numbers, data

Avoid ‘several times’, ‘a lot of errors’ or just a number, a measure without the metric. Opinions, sensations are open to discussion and interpretation

Look and prioritize hard data: percentage of cases, occurrences over unit of time or total number, etc. They will definitely help prioritize the situation and take an informed decision

Meetings

If you are in a meeting and don’t have anything to add, question, opinion, etc. Then most probably you won’t need to be in that meeting in the first place. Of course there are always exceptions, maybe the meeting is to present a new product or solution, you are in representation of an area or you are the ‘tech guy’ of your area, interested in the presentation but with little to add or ask. If not is the case then you should ask yourself if you need to be in that meeting and if the answer is ‘no’ you can evaluate respectfully decline the invitation

As someone said ‘we are time and experiences’ let’s invest it wisely

Minute of Meeting

Email minute of meetings (MOM) in my opinion are very powerful tools to align expectations, ensure that we all understand the same and are on the same page, generate commitments, evidence and follow up on future meetings. Good MOM have also an actions section with explicit owners and dates

If you are the owner of the initiative or organizer of the meeting you should consider send a MOM not so long after the end of the meeting

Also even if you are none of them but are interested in the initiative and want to explicitly confirm agreed commitments you can ask or directly take the initiative and send it

In some cases it does not even need to be the result of a meeting. It could be to agree or inform a group of people or teams interested in the topic of a commitment agreed in a group slack conversation for example

Potential MOM template:

subject: [MOM] [title-of-the-meeting-appointment]

attendance:

In my case I like to always start thanking all participants as an introduction maybe also with a quick mention of the importance of the initiative

topics discussed:

• topic 1 [initals-of-owner-of-the-action] action or next step agreed [deadline]
• topic 2 …

next steps: other owners and actions not included in any topic but related to the initiative and agreed on the meeting

Thanks again to all who participated and explicitly offer the opportunity to add something that you may have forgotten

It is key to be very concise and short

Big Bang

Related with the previous in most cases is more valuable to give feedback even if we still only have partial feedback

We should avoid the ‘all or nothing’, for example no code and then a mega pull request for the team to review

Partial changes allow partial feedback and in several cases allow other teams to start working. Sometimes other team not even expect the full answer as the next step

Early feedback also allows us to find issues earlier, misunderstandings, corrections, iterate changes

Ask questions

People don’t expect you to know everything. You shouldn’t feel that pressure of having to know about everything. You should have the complete freedom to say ‘I don’t know’ and in some cases look for the answer

In that context you should ask questions. Asking good questions is a completely separate skill. I’m definitely still learning but I can mention some tips:

• If you can get the answer with a quick investigation or calculation, you should avoid make the question as the first option
• Give options, most people want to help you and it is very valuable to have a list (small, a lot of options also could be counterproductive) to help her/him have context, understand your requirements and help you. Also it is proof that we were making some work. Give options A, B, C, you are not sure with which to choose, so the question, the other person can help you define one of those or identify an option D that you didn’t take into account
• Try to avoid the blank page, “I don’t know what to do, I’m completely blank” there could be some cases where you really are in that situation, in that case you can give a quick overview of the paths you tried, ended on a dead road and took you to this situation

Eisenhower Box

https://en.wikipedia.org/wiki/Time_management

There exist an infinite number of time management strategies and recommendations. I like to mention the Eisenhower box as it helped me recognize my time waster and organize in a better way my time

Important/Urgent: do it, you need to act immediately. A production problem, an issue in your core solution
Important/Not Urgent: defer it, needs to be done but not necessarily immediately. You can for example schedule it in your calendar
Unimportant/Urgent: delegate it, quick questions, interruptions, we can definitely do it but they are candidates for delegation
Unimportant/Not Urgent: drop it, this are usually the time wasters and are Ok to eliminate

Task timeout

Sometimes it is helpful to set task timeouts. Because they have a time window where after that window the value is definitely less meaningful or because we define that after a period of time the outcome ‘won’t pay’ the time invested

In a leadership position agree on a task timeout with team members. But also as an individual contributor you can define timeout where you have for example probably need to ask for help. If you are working on a specific issue you can set a let’s say two hours timeout where if you still don’t have a clue or a specific strategy you need to ask for help and avoid lock a task like hugging a rock that takes us to the bottom of the sea

If your leader is doing your job

We should look to take work from our leader. Learn the process, who to contact, how to act in a specific situation, etc. Develop the tools that will allow us to be proactive in future similar situations, then our leader can move his/her focus on another type of work (maybe work from her/his leader) and we are gaining new skills that will probably take us to the next level of our career

If your leader is doing your job or a job closer to your role or range of responsibility than his/her, it could be for several reasons. You are in a ramp-up process, maybe you just joined the company or the team. He/She is trying to teach you so in the short term you can start to do it. Or it is a sign of insecurity, in his/her position and capability to delegate work or in your capacity to execute the job

Every case should be evaluated, as mentioned above this is not always a negative situation but is at least a warning

If you suspect this is an insecurity case, my recommendation is basically talk, bring the situation in front. Try to understand reasoning and if there is an issue look for a solution in conjunction with both

This is also valid if you are the one in the leader position. If this is an insecurity case and depending the way, know that this could negatively affect people motivation and perceived value of his/her contributions

You cannot delegate responsibilities

You can delegate tasks, but not responsibilities

If you for example are responsible for a project delivery then you can lead a team to achieve the goal. In a very simplistic way if the goal is not achieved then the team fails, but if there is any individuality is in you

In that context there will be tasks that you will most probably want to execute yourself or at least be completely involved as you are a key part in the team success and responsible for the outcome

Service

‘We are here to serve you’ we can think that we all give service

In that context understand the requirement and why people (a client, another team, our boss) ask us for something is key and could be the differentiator in the value we add

For example if someone asks us for a glass of water: deliver a bottle of water, a half empty glass or some money to buy your own water are just optimal solutions. Probably the receptor can finish the work, but that is what we are providing in these cases: unfinished work

Definitely understanding the requirement and deliver the request no more, no less in an acceptable time is invaluable

Continuous learning attitude

We are all very ignorant. What happens is that not all ignore the same things –Albert Einstein

All have something to teach and we all definitely have room to learn something new or improve existing knowledge

It is very valuable to have a humble attitude and be always open to learn something new or new ways to do something we already know

Respect

Related to the previous topic, we all have different experiences

Don’t try to minimize the knowledge or career of other people, be respectful. This was particularly true in my case at the beginning of my career regarding other roles in the team

In most cases they are there because they were capable to fight some battles you probably are not even prepared yet

Respect first

Don’t burn bridges

AKA: Don’t be rude, be nice to people

We all have goals but also we are all people, complex beings living different situations, probably fighting invisible internal battles, challenges inside and outside the work environment

Don’t be rude, don’t push too much. The best thing that we can aspire to is to meet goals and make new friends in the process. It is all about the journey