Recently I finished reading a pretty good engineering book, so I decided to write an article about this, summarizing the main ideas. The book is "The Unwritten LAWS OF ENGINEERING", a classic.
Don't worry too much with small things
You should only worry about the things that matter. This doesn't mean that you should ignore the details of your system, but you have to start from a "macro vision", and then refine it along the development process, until you reach the "micro vision".
Demonstrate the ability to get things done
Show your boss that you are capable of get things done. Solve bugs, deliver new features, take bigger responsibilities. As Nike says: Just Do It - but with quality, obviously.
Be straight to the point
When you are writting a documentation, a report or during a call with your team, it' very important to be consise and clear in your statements. By doing this, you can repass the maximum of significant information in the minimum time. Get to the point, nobody likes attending to an 1 hour meeting, that could have been a short call or even a simple email.
Don't be too timid - expose your ideas
Speaking is difficult, even more if you are shy, but try to express yourself, expose your ideas. People who don't say nothing, are usually credited with having nothing to say.
Maintain your boss informed of your progress
Had some progress in a task? Let your boss know.
Optimize the meetings
Meetings can be very boring and also uneffective. Some tips to optimize it:
- Meetings should not be neither too large nor too small
- Prepare for the meeting
- Start the meeting giving a context of the main theme, some people may have forgotten
- Avoid off-topic discussions.
- Finish the meeting with a recap
Take the risk, don't seek too much comfort
Managers and developers tend to seek the maximum comfort during the planning of the project, which is not good. Too much comfort means slower evolution. So, Take the risk! It's good sometimes, it enforces you to evolve, be more productive and competitive in the market.
Do not criticize a subordinate in front of others
By doing this, you are causing a damage in both prestige and morale. Don't do this. Never. Also, never try to transfer the blame to someone else, if it is your fault, take the responsibility.
Give feedback and ask for feedback
Your team partners need (and want) to know how they are doing, and you want to know how you are doing. So, the solution is very simple: feedbacks. You don't build high performance engineering teams without constant feedback.
Top comments (0)