Leveraging in Software Team

All the best people that I had pleasure working with on my professional journey both have the same characteristic.

They leverage/support/sponsor others from where they’re positioned. This position that I am referring to apply to both level-wise (managerial (manager, director), or even Individual Contributor (architect)), or role-wise (QA, product manager, designer, engineer, SRE).

There are various occasion that prompt me to write about this one but it was definitely the great coworkers around me that I am grateful of.

We were discussing about how our QA team could make it possible for the engineers to also be aware about the blast radius of their change, what kind of behavior change that their code change will introduce, how to introduce the changes safely without breaking any current running flow, etc. Some people are aware of it as “shift-left”, which means that for engineers to also have the full ownership of the testing flow (which traditionally was separately completed and introduced on the later stage). It could be enabled by setting up the testing pipeline and environment, introducing engineers to the testing framework being used, sharing session, setting up a proper documentation and repository for testing, and others. This was the leverage that was mentioned which could be done by QA folks, so as to also grow and cultivate QA mindset for the engineering peers.

This I think isn’t just achieving the leveraging part (which is already great!) but even make the team more effective and efficient since the feedback loop is much faster. Traditionally bug was introduced on the latter part of the SDLC and after it was discovered it had to undergo the lifecycle from start once again on the next sprint whereas with this one we could have engineers to also be responsible for updating the test cases and coverage when they introduce new behavior. The QA team is not being the one that update all of the tests in the case of new change being introduced, which makes work faster as well.This also aligns with various companies deprecating manual QA roles and transitioning it into a more “leveraging” roles like SDET. Leverage.

We are a team of ~60 infrastructure engineers. Some have more sysadmin/devops/operations background and some are coming from software engineering background and our department head few years ago had the vision to make our infrastructure offering as a product which on the more recent days are known better as platform, and one of the earlier things that he did was to hire a Product Manager. My good PM friend establish product development process and instill product mindset into the team members which in result now for every initiatives and features we’re going to implement we started with the product question of what are the problems we are trying to solve, how do we know that this is solving our user pain points, we are conducting user interview (which I think is very awesome and rare to have in a infrastructure department), we track our metrics and our success criteria, and other product management techniques. Metrics are being shared, analytics are open for everyone to see, as it should be for vision and roadmap as well. This doesn’t mean that the role of the PM and his existence in the team is being obsolete. Rather it enhances the team because all of the product aspect could still be ensured without him having to manage one-by-one while he could focus on the strategic initiatives like product vision, roadmap, backlog, etc. For a bigger feature he still writes the PRD but for the team-specific one each corresponding engineers could even start and write their own PRD. Leverage.

This also got me thinking that this could be applied to the newly SRE/Infrastructure role that I enjoyed a lot. Rather than keeping it all under their control from network, compute, cost, security, and others, where it won’t only burden their own selves but also cripple the whole engineering flow, Infrastructure team should provide a foundation where engineers are encouraged to also have the visibility on what is going on their services with proper guard and golden path. Engineers should be able to know the health of their applications, how much does their application cost, amount of traffic going into their application and where is it coming from, all logging, metrics, and traces for their application, and useful toolings for them to take full ownership of what they are building. Infrastructure should not have been a black-box where engineers throw out what they have been writing and they don’t know how it’s being properly running and maintained. Leverage.

On the span of my career, I’m fortunate enough to work under great Engineering Manager (and in my previous company as well). And turns out what makes me feel that it’s a pleasant experience to be working under their team was because they also leverage their team members in their position as being the manager. They don’t shield their team members from away from all of the information from the upper management, changes in direction, or even for the operational work in both the team or in manager-report relationship, they are clear on how the team operates, they explain what’s the expectation on us on this role and how they could help us in achieving them, how we could them updated of our progress, etc. Even if they need to be on leave for a while, the team could still work towards the goal and progress on a daily basis because the process being established well. Leverage.

The counter-characteristic for this one was usually found at people that wants to be the man-of-the-match. They want to be deemed as the hero, that thing couldn’t work without them. They are craving for the spotlight. Even if sometimes it is a sign that this particular person is able to bring such significant value to the team because of their outstanding capabilities or domain expertise, it is not sustainable to stay that way for a long time. What if the person leaves? Or burned out? Or even if they stay, that just means that all of the work or fire-fighting related to this domain will only be able to handled by them, which is a single-point-of-failure.

One of the indicator that a leverage is being done well was that the team could still work, or even on a better performance, when the one giving leverage was away for a while, because the team has been empowered on various aspects. And on daily basis, the one giving leverage could give their efforts to be focused on another thing that is more important with bigger impact.

This also reminds me to what Peter Seibel has pinned on his Twitter regarding 10x engineer, that to be one, help other then engineers to be twice as good.

So the next time you want to achieve some goal on your team/company, you might start with the question, are the actions you going to pursue leverage others?