Driving your initiative to success
A former manager of mine once said:
"Sergei, you must know how to drive your initiative."
I thought back then: "What the heck does this even mean? Just do what you normally do and everything will be alright. Right?"
Turns out, there is much, much more to it. Initiative driving is an essential skill an engineer must master. It's especially crucial on the path to becoming a principal, because this is part of what a principal's daily routine actually is.
Types of initiatives an engineer has to drive include, but are not limited to:
- New feature development, project-level and department-level.
- Technical debt elimination, refactoring.
- Taking architecture decisions and code standardisation.
While they seem drastically different, there are universal rules and best practices one must follow to succeed.
So let's outline a few things, understanding and practicing which are critical for mission success.
It's easy to say "Hey, you must understand the task, it's your job." What I've learned over the years of practice: understanding is an ongoing process.
Imposter syndrome.
Be ready for pushbacks.
People have inertia of thinking.
People can validate your approach.
Are you fucking dumb?
Assume nothing. People will not analyze and take initiative.
Don't say "I", say "We". No blaming culture.
Everywhere you screw up, you are responsible for delivery.
Document the process.
Keep the manager posted.
Create the slack channel.
Make the decision formal. Here is a template. Helps to cope with answers like "I don't recall us agreeing on this".
Write a log after each meeting.
You can't force them to accept anything. You can only sell it.
Don't mix the sprint delivery with some refactoring, especially a non-negotiated one. It is a sure recipe for disaster, as the team members will for sure give pushbacks that will lead to failing the sprint delivery. So simply accept that the code has some flaws and move on for now, don't jump into that rabbit hole.
If you do everything alone, it's not heroism. It simply means you could not organize distributed work.
A good meme here about refactoring.
Two phases:
Initial pitch to propose the idea and gather the reaction. Why need? What are the benefits?
Detailed pitch: with code samples, etc.
Make sure people have tickets. Check how the tickets are done.
Write some e2e test scenarios in a google doc. Put together a list of issues.
Think about how the work can be parallelized. If there are blockers, nail them first.
For example, when delegating work to several FE engineers, recommend to make some re-usable widgets first, and then each engineer can re-use them for their part.
It's difficult to drive your own initiative at work when in your private life you are mostly a follower. It simply does not add up. You should listen to your heart, understand what you really want, and stick to your own agenda. If you don't offer your very own agenda, you will become part of someone else's.
