EMFR #1 - Changes In Life = Changes In Management View
What is going to happen next in my life, and why I will focus a lot more on Engineering Management.
If you are reading this email, thank you. You are one of the first 10 subscribers of my newsletter. I will speak about Engineering Management, IoT, Technology, but mainly about the first one. In the last years, I discovered I love helping other people become successful.
What is EMFR? It stands for Engineering Management, For Real. Is a set of resource and practices I learned from real-work experience and by looking at many resources (books, video, course, etc.). I will share with you as much as possible while I will continue learning.
In the last 7 years, I worked at Arduino, started as a Linux Admin, then turned out to be a Product Manager of Arduino Create, and finally a CIO with a lot of duties, mainly about People management, recruiting, hiring, creating career paths, and helping the team in improving the quality of our products, the effectiveness, and the happiness of all of us. I worked as a DevOps Engineer at Cloud9 (then acquired by Amazon AWS). I managed a team of more than 40 developers and managed one of the world's top 2500 websites.
That apparently worked quite well; now it is time to do something else, something different, to help you. Sharing my knowledge!
What I Learned So Far, and What You Can Learn Too!
People are more important than anything else in many fields, including Engineering. If you want to read more on this, I strongly advise reading the book Peopleware and discussing what you have found with me.
If you want a great performing team, then you have to build trust. The higher your role, the higher the expectations. This is good because you can make a huge impact, Trust is not something you can buy, but something people will think you deserve. I will explain to you a simple way to build trust across your team in the coming weeks.
Guide your team by telling them Why, not how to do things. You hired your team, and you trust each of the members (if you do not trust them, better stop working with them completely). If you trust them, it is because they are the best people you can work with to solve your problems, so why should you tell them how to solve a specific problem? In the coming weeks, you will discover why it is best to let the team solve your problem instead of solving it yourself.
I have seen some teams struggling while rebuilding “almost” the same thing over and over again. Why was that happening? Goals were not clear, so your team, willing to help the company, comes up with a solution, but if there is a lot of uncertainty, then the risk is to change scope too often, which frustrates people. That has many bad effects; context switch and lack of focus are your worst enemies. To avoid it, I discovered some effective strategies to align your team and even the whole company.
I learned many other things in the last 13 years of my career, and I will share a lot more with you and everyone else you want to involve.
If you want to know more, help me reach a bigger audience to build a community out of it together. Then share this newsletter!
You can also follow me on Twitter
If you like emails and want to ask me anything or give me feedback about this first newsletter, hit reply to this email, I will get back to you quickly.
Thank you!