Work according to your scope of influence

When you’re officially (or unofficially) the owner of front end development practices across a whole organisation with multiple teams, you have to play a fine balancing act.

You can’t dive into each an every team and help them make each and every decision.

Nor can you can’t sit away in your ivory tower and issue abstract directives from afar and expect them to be followed to the letter unquestioningly.

When your scope of influence opens up from one team to many teams, the way you approach work and decision-making needs to change accordingly.

In most organisations, there is little guidance on how do manage this, or even on what the behavioural expectations are.

But if you’re really lucky, you have an explicit, concrete and transparent career framework.

Buffer’s engineering progression framework (sometimes called a ‘career ladder’) is one of my favourite examples, which Buffer’s VP of Engineering Katie Womersley writes about here.

Instead of focusing on individual skills, Buffer’s framework describes the scope of influence of each step, and by association how the work is conducted.

For example, a Software Engineer’s scope of influence is mostly themselves and their own tasks. To operate well, they take a learning-based approach to contributing individual work.

On the other hand, a Principal Engineer’s influence extends to the whole organisation. Necessarily, this requires understanding business needs and making long-term strategic decisions (coincidentally exactly the type of thing I like to waffle on about in these emails ;-) ).

What’s your real scope of influence? How have you modified the way you work as it has changed over time?

All the best,

– Jim