Circles of impact

The first moment of truth

There is a lot to of literature to read about differences between a developer, programmer and an engineer. Many other ready materials also about the career paths and how to climb the career ladder from a junior engineer towards a Senior. Additionally, some other niche readings about climbing furthermore; either in the technical leadership or the people management paths.

Our industry still young, not even a hundred years yet! However, while growing it took many other industries as mentors. Before the Agile era, teams learned how to manage software projects same as construction. Architecture, Biology, Neurology and Genetics, sound familier?

I realized while talking to one of the architects in my project that we share the understanding of why it's not that easy to (just lead)! So, In this article I share what did I learn from leading a distributed team during the past couple of years, and how I visualize it in my mind while planning my days.

Circles of impact

Teams are just like systems, but they don't operate in a world without external factors affecting them, otherwise it would have been an easy task just like writing a declarative code! We need to operate with multiple agendas from every stakeholder. At the end each person who has a stake in what we're working on would have an impact.

For me, as a Software Engineer, and one of the project's stakeholder I think of my personal impact on a project in three layers enclosing each other. Take a cross-section; and you'll start seeing "Circles of impact"!

• Inner Core : Individual contributions.
• Outer Core : People you lead
• Crust or outer-shell : Company, product or project

Outer shell

This is an interchangeable tier, which depends heavily on the project you're working on, the company, and the engineering culture. In this tier we usually answer some questions; for example, but not limited to:

• Track success/failures from the previous product experiments (quarter or yearly basis).
• Prioritize the company and product growth activities over the next period of time be it a quarter or a year.
• Answer: How this will impact technology? Perhaps we need to revisit the architecture characteristics, functional or system requirements (-ilities).
• Answer: How would it impact people? Do we need to rethink team topology, What kind of information needs to be passed down for them to achieve it the right way?

I believe it's an important layer; which requires full attention during the time spent working on any of its topic. It has a great deal of impact on your lifetime during this cycle or period of time. It impacts how to create a strategy for your individual contributions, prioritizing effort to spend, team dynamics, the people you mentor and coach, and finally the outcome of this project.

Inner Core

At the core, lives all the individual contributions. For an Architect, Principal or any technical leader it's a must to continue to contribute to the codebase. Knowing the crucial inputs needed for architecture evolution by asking some questions and watching for:

• How the codebase evolves? Tooling, number of contributions, LOC, testing ...etc
• Is the architecture applied?
• Is the required outcome of the software achieved?
• Any hidden or non-functional requirements?
• Any issues with the developer experience?
• Any part of the application cries for refactoring or more abstraction?

For me, this can take in some days approximately 50-70% of my time.

Outer Core

Here lies the people you lead, this layer in the middle for a reason. It's a supporting layer to both the inner-core and the outer-shell. At a glance; without people, project's won't get completed and leader won't be leading anyone!

Take mentorship as one example of the activities, how to prioritize whom to mentor and whom not to? at the end every engineer is smart enough to know what to do for personal development. An engineer want to know more about infrastructure, someone else likes animation and appreciates a good UX, another is fascinated by developer tooling.

Can you mentor someone, technically, if the topic is not interesting to you? Would you've a constructive feedback if you didn't have enough experience in that matter? If the answer is no, I would directly suggest seeking another mentor! In my experience, the efficient mentor:mentored relationship achieved by mutual interest, or having same learning/development objectives.

For people, whom are the source of inspiration, when it comes to company growth. You'll need to help engineers achieve their personal development plans while getting those quarter goals or OKRs achieved. I say that's a very good optimization when planned and done right, and all parties achieve a win-win situation 😊.

You see why this layer is pretty critical! To gain the maximum impact from this layer; I try asking questions to find common development interests to know whom to focus more with, all while keeping company OKRs or goals in mind.

Leader time-management

Each of these layers is needy! It just takes time, and we might need to switch context now and then. I like to prioritize:

• 30% mentorship and peopleware,
• 50% coding, documentations, experimenting and individual contributions,
• 30% architecture: taking a step back seeing how all fits together
• 20% Random topics that pops every day. Hopefully not an incident next Friday!

Do the math, and accept the challenge! Say "No!" when you need.

Cluster your day and see what suits you. For me it's about having strict mornings and end of the day, while having a loosely planned afternoons.

Conclusion

That's how I visualize, it helps me cluster my routine activities, scope and track the impact of these activities. Over the year, my practice evolved using this model. Every layer empowers the other and sustain the work dynamics and personal development. Perhaps there are some other models out there which I don't know about them yet.

Our industry shaped with people practice; sharing such practices evolves our industry, while we keep using patterns of practices that work, and avoiding the anti-patterns that could hinder it. Let me know what you think, do you have a similar model and how its like in your workplace!