Junior Engineer (2 Years)

This phase was enchanting—it marked the inception of my fascination with coding. I was finally interacting with real codebases that served users within my organization, though often, I felt like a chaotic force, disrupting systems without fully understanding them.

Most of my time was devoted to minor feature developments and fixing straightforward bugs. Debugging became an excellent learning opportunity, allowing me to grasp the intricacies of systems and code. I made numerous errors and relied heavily on the support of my peers.

Eager to tackle challenges independently, I sought collaboration with seasoned Developers to gain insights and constructive feedback. At this stage, it’s essential to absorb as much knowledge as possible. Online courses, particularly from platforms like Pluralsight and Udemy, can be beneficial. Building numerous Pet Projects and Proof of Concepts can also offer practical experience without the risk of damaging live systems.

Reading List: - Clean Code — Robert C. Martin - Refactoring — Martin Fowler - Docker Deep Dive — Nigel Poulton

Senior Engineer (1 Year)

By now, I had a somewhat superficial understanding of the technologies my team employed. I was experimenting with many new technologies unfamiliar to my team, injecting fresh ideas and perspectives into our processes.

I documented my experiments on GitHub, showcasing my early work, much of which I now view as subpar. Fortunately, I had an exceptional mentor during this period who nurtured my growth rather than stifling my creativity. His support fostered a learning environment that I hadn’t encountered before.

However, my eagerness to implement new ideas often led to overcomplicating projects with various architectural patterns and technologies, which ultimately proved detrimental. Understanding team cohesion and the tools at our disposal is a lesson learned only through experience, often the hard way.

At this juncture, I was unaware of the extent of my ignorance. I exhibited a mix of arrogance and naivety, common pitfalls in technical fields, often referred to as the Dunning-Kruger Effect. I was at the peak of my overconfidence!

My advice for others at this stage is to recognize that you may not know as much as you believe. Seek guidance from experienced colleagues; there’s much to learn!

While exploring emerging technologies is vital, it’s equally critical to develop a thorough understanding of the core tools your team utilizes. I focused on mastering .NET, Angular, SQL Server, Kubernetes, and Azure, which accelerated my progress.

During this time, I was driven by long hours and an unhealthy disregard for my mental health. Despite my passion for coding, the stress I placed upon myself became overwhelming, leading to my first encounter with serious burnout. This experience taught me the importance of managing stress, and I found solace in regular exercise and adopting a dog.

Reading List: - CLR via C# — Jeffrey Richter - Domain-Driven Design: Tackling Complexity in the Heart of Software — Eric Evans - Implementing Domain-Driven Design — Vaughn Vernon - Designing Data-Intensive Applications — Martin Kleppmann

Tech Lead (2 Years)

With newfound technical competence, I was entrusted with leading a group of Developers. This role shifted my focus toward overseeing code quality, development processes, and managing releases—all while adapting to the unfamiliar responsibility of team management.

Unfortunately, the skill sets required for Development and Management are vastly different. My team looked to me for direction, advice, and feedback, and I often felt out of my depth.

Many Engineers in this situation tend to ‘wing it,’ believing that technical expertise equates to management capability. This mindset often leads to failure or toxic team dynamics.

Fortunately, I was surrounded by experienced colleagues willing to share their knowledge. If you lack such support, numerous excellent resources on Software Management are available. One book that profoundly impacted me was The Manager’s Path, serving as a practical guide for Engineers in leadership roles.

As a Tech Lead, my focus on technical learning needed to shift. Establishing a well-structured development process became essential for the efficiency and well-being of the team, encompassing documentation, testing, DevOps, code review, and agile methodologies.

Although I continued coding and reviewing code extensively, I initially maintained a mindset that favored my approach over others. This attitude created friction within the team. Over time, I learned that promoting clean, maintainable code and standardizing practices across our codebase were far more effective.

I soon had a cohesive, productive team. While I felt comfortable leading small group meetings, the thought of presenting to larger audiences was intimidating. Observing senior leaders confidently managing and presenting only heightened my anxiety.

Reflecting on this period, I wish I could tell myself that feeling intimidated is entirely normal; leadership doesn’t materialize overnight.

My manager once volunteered me to present at a major conference on Containerization and Microservices—topics I felt knowledgeable about but was terrified nonetheless. As I prepared, my anxiety transformed into comfort, and by the time of the presentation, I felt confident and engaged with the audience.

This experience marked a pivotal moment in my career, affirming that I could rise to challenges!

Leadership and Public Speaking skills develop over time and require practice. If you relate to my apprehensions, consider gradually engaging in opportunities such as team presentations, mentoring juniors, or conducting interviews to ease into leadership roles.

Reading List: - The Manager’s Path — Camille Fournier - The Phoenix Project & The Unicorn Project — Gene Kim, George Spafford, and Kevin Behr - Clean Agile — Robert C. Martin

Senior Architect (2 Years)

At this stage, I felt confident leading Engineering teams and had recently completed a significant project involving the design and development of our team’s Kubernetes-based Infrastructure Platform. My technical knowledge was robust, complemented by several expert-level Cloud and Kubernetes certifications.

A major global eCommerce initiative emerged, and my team selected me as the Lead Architect. This role required overseeing five different Development teams, marking a significant step up in responsibility, including managing senior Engineers.

This project proved to be a trial by fire, demanding rapid adaptation and learning. While overwhelming, such projects often yield the most growth. An effective Software Architect must possess broad knowledge, diverging from the deep technical focus of a Developer.

I immersed myself in Software Architecture literature and engaged with other Architects within my organization. At this stage, I found that books often provided deeper insights into complex topics than videos or blogs.

Equipped with newfound knowledge, I realized the importance of not becoming an ‘Ivory Tower Architect.’ Staying engaged with the team and understanding their daily challenges is crucial; otherwise, decisions that seem optimal on paper can disrupt team dynamics.

An Architect’s role extends beyond creating diagrams; it involves fostering effective development processes. I facilitated Event Storming sessions, allowing teams to collaboratively design solutions and cultivate shared understanding.

Furthermore, I discovered the connection between product architecture and team organization. My ongoing education in Management and Leadership paralleled my technical studies, leading me to the book Team Topologies, which helped unlock my teams' potential.

Conway’s Law emphasizes that organizations produce designs mirroring their communication structures. This principle guided my design and organizational strategies, advocating for a ‘Team First Architecture’ where team organization aligns with the envisioned solution architecture.

Microservices and Microfrontends, while often criticized for their complexity, are essential for larger teams. These methodologies enable independent work and deployment, preventing inter-team conflicts.

I also embraced the concept of Platform Teams, dedicating a portion of our Engineering resources to cross-cutting platforms. These included components like our Angular Design System, Backend libraries, and a distributed messaging system, all foundational to our product’s success.

Not every decision I made was optimal; I sometimes overcomplicated designs. While complexity can be necessary, it’s vital to ensure it truly serves the problem at hand. A key lesson I learned was to delay significant technological decisions until the last possible moment, starting with the simplest version of a solution and iterating as more information becomes available.

Reading List: - Fundamentals of Software Architecture — Mark Richards and Neal Ford - The Software Architect Elevator — Gregor Hohpe - Building Microservices — Sam Newman - Clean Architecture — Robert C. Martin

Head of Platforms (3 Years)

The implementation of Team Topologies and Platforms in my previous project revolutionized our organization’s efficiency. With rapid delivery of robust solutions, my team recognized the need for a dedicated Platforms Team, and I was chosen to lead this initiative.

This new role required a heightened focus on Strategy and Vision, encompassing operational and leadership elements across the entire organization rather than a singular product.

During my time as Head of Platforms, I also navigated the rigorous Director process, which scrutinized my value beyond my immediate team. This experience reignited feelings of Imposter Syndrome, a common challenge for those stepping into significant roles. Open discussions with my team and constructive feedback helped me navigate these feelings, reinforcing that I was performing well.

Over three years, we developed nearly 50 Platforms to enhance our Development teams, ranging from comprehensive Kubernetes Infrastructure to simple Wikis for team standards.

One standout Platform was a Template Microservice Application, capable of generating entire solutions at the click of a button, adhering to our Development standards.

I also established our DevOps capability, drawing from my previous experiences leading various initiatives. You can read more about my approach to building an effective DevOps Team in my other writings.

The primary challenge in this role was driving adoption of our Platforms. I found that creating Communities and Champions to educate and support the team accelerated this process.

Reading List: - Team Topologies — Manuel Pais and Matthew Skelton - Site Reliability Engineering (at Google) — Chris Jones

Head of Engineering (Current Role)

My work on Platforms solidified standards and consistency across the team, enhancing architectural patterns, libraries, tooling, DevOps practices, and testing frameworks. This role granted me oversight of all team products and processes, empowering me to implement improvements.

When I was appointed Head of Engineering for the entire team, I felt immense pride but also overwhelming dread—Imposter Syndrome returned with a vengeance.

Suddenly, I was responsible for nearly 100 Engineers working on around 30 live products, following in the footsteps of a highly successful predecessor. Transitioning into this role was intense. My familiarity with Platforms provided a solid foundation for managing our Development processes, but the aspects of People Management and Governance were a new challenge.

After a few hectic months, I gained confidence and began to navigate my responsibilities effectively. While the Engineering Team was in a strong position, I aimed to enhance its performance and imprint my vision. I implemented the OKR (Objectives and Key Results) framework to define my strategy and initiatives for the year. OKRs are a powerful tool for breaking down goals into manageable steps while ensuring clarity in tracking progress.

Establishing Engineering OKRs allowed me to streamline priorities and communicate my vision with the team. My objectives reflected my core beliefs as an Engineer, focusing on Learning, Testing, Collaboration, and Rigor.

With so many initiatives underway, I relied on my talented team to help lead projects, allowing me to scale my vision and provide opportunities for others to demonstrate leadership.

Some changes I’ve introduced include: - Collaborative Team Code Katas - Architecture Design Authority - Senior Engineer Led Learning Series - Style Guides and automated refactoring - Software-supply-chain governance and testing - Adoption of Generative AI coding tools

Thus far, the journey has been remarkable, filled with learning and growth!

Reading List: - Software Engineering at Google — Tom Manshreck, Hyrum Wright, Titus Winters - An Elegant Puzzle: Systems of Engineering Management — Will Larson - Ask Your Developer — Jeff Lawson

For those passionate about Programming, a rapid ascent is possible. However, it requires more than merely completing assigned tasks; it demands relentless learning, experimentation, boldness, and a willingness to embrace failure. The rewards are abundant in this thrilling and fulfilling profession.

Programming transcends mere employment; it is an art form. If you lack this passion, your journey in the field may be limited. Seek mentors, connect with like-minded individuals, and cherish the community of Programming enthusiasts.