Goal-Setting Made Our Team 10X Engineers
After 10 years, some developers have 10 years of experience, and some have 1 year of experience 10 times
Ok, maybe 10x engineer is a strong word. Nonetheless, we became very good engineers over time.
I remember vividly when I joined my current company a few years ago. I had hardly lasted two weeks before my engineering manager mentioned that we needed to agree and set goals whose progress would be reviewed at the end of the quarter.
“What a bummer?” I said to myself, “I thought this was a cool company. So they are into all that corporate mumble jumble?”
I had previously worked at two other start-ups where I had never had to set goals. So as soon as I heard that I was expected to set goals, I resented the idea.
I couldn’t have been more wrong. It was blessing in hindsight.
Goal-setting as junior engineer
As a new joiner, my goals were already established, and they were very achievable, primarily aimed at familiarising myself with the company, the team, and the system I was working on. Examples included updating some documentation, ensuring that I understood the deployment process and deploying a release to production at least once, e.t.c
One of these tasks involved implementing a small feature. This implementation proved invaluable in helping me become acclimated to the extensive JavaScript codebase.
To this day, we continue to assign new joiners small features, as we find it to be an effective method for facilitating their understanding of the codebase. Implementing these features allows them to navigate different modules and gain familiarity with the system more efficiently.
Three months later, the quarterly reviews arrived, and I had successfully achieved my goals, leading to the completion of my probationary period. Following the review process, new goals were set for the upcoming quarter, marking the beginning of a new phase of objectives and growth opportunities.
This time around, I faced the challenge of setting my own goals, which proved to be a bit challenging. I endeavoured to strike a balance between setting goals that were neither too easy nor too difficult to achieve.
Throughout this process, I sought guidance from my engineering manager to ensure that my goals were aligned with the company’s objectives and my professional development needs.
The goals encompassed various activities aimed at enhancing the project I was working on. These included integrating TypeScript into the project, adding tests for specific modules, updating documentation, and more.
During my earlier years as a junior to mid-level software engineer, my goals were primarily focused on improving the codebase in different ways. Additionally, I set personal development goals such as reading a book and delivering a company-wide tech talk. It was one of these personal goals that fundamentally shifted my perspective on the importance of setting and achieving goals within the company.
At that time, my engineering efforts were predominantly focused on the frontend. Despite having a design team and relying heavily on frontend frameworks like Ant Design, I recognised the importance of gaining a deeper understanding of UI/UX principles.
After conducting some quick research online, I came across numerous recommendations for “Don’t Make Me Think” by Steve Krug. I decided to add reading this book to my goals for the upcoming quarter.
I really enjoyed reading the book. It taught me some very valuable lessons on DIY usability testing and UX. In fact, I recently wrote a piece on it.
In that same quarter, I delivered a company-wide talk on the lessons I had learned, sharing insights from “Don’t Make Me Think” by Steve Krug. As a result, our team began implementing the principles outlined in the book. I also facilitated the first DIY usability test.
I felt a sense of pride in my accomplishment, as this experience demonstrated the power of committing oneself to pursuing excellence, even in the face of challenges. It reinforced the notion that, with determination and dedication, one can achieve significant goals and drive positive change within a team or organization.
Goal-setting as a senior engineer
Moving forward in my career, I have become more adept at setting goals, and the complexity of these goals has evolved as I have progressed to a senior engineer role. Having worked on various projects and with different technologies and languages, I am currently primarily focused on backend development.
My current goals are centred around mastering distributed systems, system design, and cost reduction. This interest stems from both personal motivation and the need to address performance bottlenecks in our scaled-up system. As our system has grown over the years, we have encountered performance challenges.
At a point, a prominent SQL query in our Postgres database originated from an internal package managing billing. Each successful API call by a user led to an increment in a usage counter specific to that user in the database.
This had always worked fine for almost 10 years without challenges. However, as the volume of traffic increased over time, issues began to emerge. Upon thorough investigation, I concluded that the API call increment could benefit from a weaker consistency model, such as eventual consistency.
I devised an implementation plan that received approval, and I went ahead to implement it. The number of writes to update the API usage counters decreased by an average of 98% per month.
From clock punchers to 10X engineers
It’s inspiring to see how goal-setting has positively impacted not just my own development but also that of my teammates. I vividly recall one teammate who was extremely nervous before delivering his first company-wide tech talk a few years ago. Since then, he has given numerous talks comfortably.
Similarly, I also experienced nervousness when facilitating tech talks a few years ago, but over time, I became more accustomed to it.
Another team member executed performance optimisations at the database level, leading to the elimination of one of the database replicas, thereby reducing costs.
Engineers from various teams have collaborated on internal libraries belonging to other teams, some even picking up new languages along the way.
Most team members have ended up being overachievers over the years.
In the last couple of years, the company has shifted from conducting quarterly to bi-annual review periods. As a result, employees have shown increased eagerness to take on more ambitious objectives, capitalising on the extended duration between evaluations.
Conclusion
The intention of this article isn’t to laud a company’s goal-setting procedure as a panacea for career advancement. Instead, its primary focus lies in highlighting how striving to accomplish incremental, atomic goals can propel individuals toward becoming overachievers.
If I transition to a different company without similar goal-setting principles, I’ll still set individual goals.
Engineers who pioneer languages and rapidly assimilate new concepts have attained such proficiency through unwavering dedication and persistent practice.
At the time Bjarne Stroustrup was designing C++, he was familiar with about 25 programming languages.
After 10 years, some developers have 10 years of experience, and some have 1 year of experience 10 times
Conversely, opting to remain an uninspired engineer would likely result in seniority based solely on tenure rather than genuine expertise and innovation.