Categories
Development

3 tips for when providing and receiving feedback

Photo by Jeremy Bishop on Unsplash

Feedback is a critical tool for people’s development and growth. It allows people to understand their shortfalls, see how their behaviors are perceived, and confirm if actions are producing the expected results. It is also a slippery slope where emotions can range from extreme excitement to desolation depending on how it is delivered and what its content includes.

In this article, I share a few tips from each perspective: giving and receiving feedback. In general, I like to follow the approach presented in the book No Rules Rules: Netflix and the Culture of Reinvention but here I incorporate a few personal touches after reflecting on the best and worst feedback interactions over 15+ years.

Providing feedback

#1: Do not expect anything back

Provide feedback for the sake of helping someone else. If you give feedback to promote yourself or expect to receive something in return, you should just stop it. That may backfire and damage your reputation when people realize that your intentions are not genuine, or frustrate you if you do not get anything back. You should think of feedback as a gift.

#2: Accept that your feedback is disposable

Understand that whoever receives your feedback has no obligation to respond, react, or implement it. That person can listen to it and politely decide not to take action. And guess what? That is totally acceptable. If you love your feedback so much that you would be disappointed if that is not adopted, refrain from giving it to start with.

#3: Stop it if it is not well-received

People react differently to feedback. Some people may get defensive and push back. If that happens, firstly check if you can improve how you provide the feedback. How you deliver a message is as important as its content. If the delivery seems appropriate, I recommend stop providing solicited or unsolicited feedback to those people. If they happen to ask for feedback again, clarify in advance what your expectations are and are not. For instance, make it clear that you are not attached to your feedback and that you do not expect anything back. Additionally, share which kind of reaction (like trying to justify themselves even before you finish your comments) does not encourage you to provide further feedback.

Receiving feedback

#1: Do not create a Frankenstein

Requesting feedback from multiple people can be a priceless way to approach things from different perspectives. Having said that, be cautious with which suggestions you will adopt. Whether you are asking for peers to review a doc or for insights into your long-term career plan, you are the one who best understands the whole picture of what you created or want to create. While pieces of feedback may be valuable in isolation, adopting all of them may lead to a Frankenstein artifact that loses its original goals or becomes hard to parse with a compromised flow. Politely declining a suggestion and sharing your rationale for that can lead to a better overall outcome while nurturing the relationship with those who invested their time to help you.

#2: Listen and hold the urge to react

Feedback can be hard to hear sometimes. It may sound unfair, it may feel wrong, it may seem misinterpreted, and it may also be true but just hard to swallow. Whatever it is, listen to it and let it soak in at least for a few seconds. If you feel the urge to respond, ask for a clarifying question or just repeat what you understood to buy you some time to process it, understand where that person is coming from, and respond to it in a more deliberate, less emotional way. Assume best intention until proven otherwise and try to see that as a learning opportunity.

#3: Recognize when you get valuable, actionable feedback

Useless, shallow feedback is straightforward and quick. Thoughtful, well-constructed feedback takes time. You should let people know when someone provides you with helpful insights. Recognize that on one-on-ones but also on broader forums. A public “Thank You” will reward it in a way that will reinforce that type of behavior. If you want people to provide valuable feedback, you should consider giving them a broad shoutout when that happens.

Categories
Development

From a book per year to 20+

Reading was (very) boring when I was a teenager. I could never read more than a few pages without falling asleep. Literature exams were stressful since I used to either skim through the books or ask people around what the ‘story’ was about. It was just not my thing. Fast forward many years, and somehow I started enjoying reading. But what has changed? Maybe I just got old(er). Maybe not. Let me take you through what I believe drove change.

Understand why I disliked reading

When I was a kid, I used to read entertaining books at school. Then when I was 12 or so, I had to start reading classical ones. Written ages ago, those books were just not compelling to me. The language was archaic, and the stories were too introspective and sometimes cryptic. After years and years of having to deal with them, I couldn’t bear reading.

At that time, I didn’t realize that my problem wasn’t about reading. It was about the type of books that I was required to read. Once I understood what was deterring me from books, I allowed myself to try new topics such as business development and psychology.

Set goals

Trying new topics was not enough though. I needed more activation energy to get me out of that get-this-book-out-here state. In my case, setting goals and challenging myself kicked off that change.

I’d been setting new year resolutions for several years, and it was time to set a goal for the number of books to read. The first year I set a goal of 12 books and read an impressive total of one. Not quite a success. I was being a bit unrealistic. The following year I set the goal to six and made it public using goodreads.com. Then it’s was not hidden in a private spreadsheet anymore. People could see it. I don’t think anybody looked at my challenge, but that pushed me anyway, and it made the difference.

Set a realistic goal, make it public, and find buddies or join reading clubs to make yourself accountable.

Read multiple books at the same time

Once I could read at least a few books per year, I had to be more efficient to double that quantity. I found that keeping multiple books in progress worked out great.

During the morning, I usually read a technical or development book. It can go from organizational culture to software architecture, but it’s about something that I want to retain to apply to my day-to-day job. At night, I prefer reading novels or something very light and entertaining. Those are books to have fun instead of accumulating knowledge.

I do recommend reading Why We Sleep by Matthew Walker to understand the reasoning behind this strategy.

Dedicate time to it

Unless you’re willing to dedicate time to reading, the previous tips won’t make a dent. I’m still looking for a book that makes my day longer than 24 hours. Since that didn’t happen yet, I had to choose what I was willing to give to allow for reading time.

Replacing screen time with reading time was the easy-to-pick-but-hard-to-implement choice. No phone after 9:30 PM and setting a resolution to do that at least five days a week was the way to go. That improved my sleep quality and freed up 5+ hours a week.

That helped with my novels, but what about the time to read those technical books during the day? Reserving 20 minutes/day before starting working addressed that issue. That’s almost 2 hours during weekdays.

By making these changes and adding the weekends to the equation, I could find around 10hs per week for reading. That was a game-changer.

Write about what you read

Writing about what I read happened to motivate me to read more. I was writing articles here and there on LinkedIn or on my blog to improve my communications skills. It turned out it had the pleasant side-effect of pushing me to finish books faster because I was excited to write about them. It doesn’t necessarily have to be an article. It could be a more involved review on GoodReads or Amazon.

Summary

  • Think about your past, bad experiences when reading and try to root-cause it;
  • Set goals and find ways to make you accountable;
  • Optimize your reading rate by keeping a couple of books in progress;
  • Eliminate wasted time to allow for reading;
  • Write about the books you’ve read;
  • and have fun!

Curious about what I’ve read in 2021? Check it out!

Categories
Program Management

If you’re a manager, invest more time in your tech skills

It’s quite common to find people who used to have technical positions earlier in their careers and then moved to management positions. There is nothing wrong with that career path but in some cases, those professionals forget to keep up with the technology evolution and end up missing great opportunities in their careers.

Consider, for instance, a Java developer who started her career 10 years ago. After 4 years she was promoted to manager and hasn’t been involved with Java coding for the last 6 years. You can (safely) assume her Java skills are so outdated that she’s not able to do a code review or design a microservice with Sprint Boot anymore. Fair enough, but when will a manager have to do that?

In a fast-paced industry with new frameworks popping up pretty much every month, the amount of content been produced is at the same time astonishing and impossible to keep up. So, if a manager can’t keep up with the speed technologies evolve, why should she even bother to try? Shouldn’t she just rely on her technical colleagues?

Inefficient communication is one of the main causes of project failures

Credibility is key and a solid background can enable that

Communication issues are usually among the top 5 reasons for project failure or challenging execution. Different elements contribute to inefficient communication, but establishing a common language is crucial for both the sender and the receiver to be on the same page about the topic being discussed.

A manager with technical skills can leverage the appropriate terms when talking to her development team to reduce miscommunication issues. Moreover, people usually get more engaged and receptive when they recognize the other ones have a similar level of understanding about the topic. Have you seen developers rolling their eyes when somebody tries to show off his technical skills and end up stumbling over?

Besides, having technical knowledge helps managers when elicitating requirements, troubleshooting issues, handling critical incidents, bridging the communication between developers and executives, and managing project dependencies. Finally, credibility is key and a solid background can enable that.

Projects are getting more and more complex and specialized

Try to think about Software Development projects you were involved about 10-15 years ago. If you were not a kid at that time, you might have remembered some sort of distributed application consuming a data source (most likely a relational database) and providing results to the user in a somewhat simplistic interface. Now let’s get back to today’s reality.

When you look at the current scenario, it’s hard not to think about integrated solutions that demand data analysis/processing, artificial intelligence, consume different services, and provide multiple different UIs. Basic client-server DB applications have become commodities and no company can endure unless they embrace very specialized and deep knowledge from areas like machine learning, augmented/virtual reality, data processing, continuous delivery, and statistical analysis.

As a manager you’d be required to know at least at a high level:

  • What those technologies are used for;
  • How they can be incorporated in the business to generate more revenue;
  • How to get started with them;
  • Which alternative approaches exist and their pros/cons.

To get at that level you could 1) read the basics about the technologies, 2) join and actively listen to design sessions, and 3) have fun coding in your ‘spare’ time.

Influential people know their sources

Power is the ability to influence others and it can be identified in 5 forms:

  • Formal: when you’re empowered to take decisions;
  • Reward: when people realize that you’re responsible for rewarding them by deciding salaries, promotions, bonuses, and so on;
  • Penalty: when people perceive you can penalize them if they don’t follow your directions;
  • Expert: when people perceive you possess important functional knowledge;
  • Referent: when people enjoy working with you or in the project you manage.

Formal and Reward types have to be granted and do not depend solely on the manager. Penalty may be effective, but it usually activates the sympathetic system which brings more stress to the relationship. Referent demands time and development of soft-skills which are quite hard to change. Expert power can be your best ally to enhance your ability to influence and lead your team.

Major tech companies look for Technical Managers

Understanding the market demand and how high-performing companies (like FAANG) structure themselves can give you a few hints about the kind of professionals that companies are looking for. If you follow these companies’ news or know people who work for them, you know that they have different flavors of technical management positions:

/Technical(.*|\s) Manager/g.

  • Technical Program Manager
  • Technical Engineering Manager
  • Technical Project Manager

That model is already being used as a reference by other companies. So, career-wise, deepening your tech expertise can help better positioning yourself for high-demanding positions.

Wrapping up

Putting the hours to learn technologies, even when you won’t immediately apply them, will pay off in the short to medium-term. Your team is more likely to value your opinion and feel like you’re one of them. Tech skills can be your competitive advantage if you enjoy getting your hands dirty, but as Uncle Ben says ‘with great power comes great responsibility’ 😉 . There are a few pitfalls that you need to avoid not to backfire your plan, but that’s a subject for another post.