Being a Principal Developer
How to become a force multiplier
While my writing generally focuses more on the developers transition to management, I thought I would share a post I wrote many years ago when I was a principal developer. It highlights some of my thinking back then as I was deep in that role and trying to express to others in my organization what I felt like the role entailed. I might add a few things now but I really like the tone of someone who is in the role so I have left it as a historical record.
Be a force multiplier
A principal should be able to keeping others moving and productive, this is just as important as keeping themselves going. This can be done in a variety of ways. One way is to start a project, make sure you understood the landscape and what needed to get done, maybe sudo code a bit and then implement the first few building blocks. At this point you would look to get other people on the team involved because once you have the vision you can direct people easier if they got stuck. If you don't hand it off you can't start working ahead enough to prepare the next project to be "shovel ready" for the team.
Not a principal developer? No problem. There are probably junior people on your team that can use direction and once you have the vision it is easy to bring someone along in this manner.
Lead from the front but not too far from the front
A principal should know the code inside and out. They should be writing and thinking about the code but if they get too far into the code they will cease to be a force multiplier. There's a fine balance. They can't disappear for 3 days and go heads down or the team will suffer. They need to constantly be engaged with the code but also with the other developers to make sure things keep moving. So never silo yourself and if you find yourself being siloed follow the force multiplier pattern.
Know the "why" and make your product manager happy
As developers we LOVE technology, code architecture, naming things, drinking the IDE Kool-Aid, and dying on various other hills. This is actually what makes development so fun and interesting. But you need to know why we are building what we are building. This is so important since at the end of the day the customer doesn't care what you built it with, they just want it and they want it yesterday. One way to accomplish this is to be in constant, direct communication with the product manager. This will help you know what order to do things in and what things are REALLY important and what things are kinda important. This will help you direct resources and know when you need to jump in and help a struggling story over the line. Most of all it will make the product manager and the development manager happy, which is a good thing.
Hold the line and be the example
This is one area we all struggle with. We don't always check-in well tested code, write good documentation, or stay on task. If we don't hold ourselves accountable it is hard to hold the team accountable for it either. You can always try to adjust this and become more disciplined but it is hard once a precedent has been set. Know that you are setting the expectations with your actions more than your words. When you have to hold the line you need to do so by explaining why something is important to the team and the individual. If you can't do that then it just may not be that important.
What you might actually do as a principal
This is totally up to the company you work for but in general here are some of the things that might be expected from a principal
Advise product manager on technical issues
Set the tone for application testing
Set the tone for project documentation
Look for and handle technical blockers for the team
Communicate team technical needs (eg. outdated hardware)
Advise management on product timelines
Keep management informed of goal progress and attainment
Triage defects and advise on impact to product and timelines
And so much more…
Its more than code
As you can see the role of a principal is way more than being a good coder. These skills are harder and require balance. For example you have to hold the line but you should not be a tyrant. You have to lead from the front but not get too buried in tasks that you cant help your fellow teammates. Most importantly these are things we can all do from the jr dev to the CEO. It is all about being an effective leader.