Project management, while challenging, can be a rewarding job.
A common approach in growing software companies is to convert senior developers into managers. I, too, have taken part in this process. In fact, a few times over the years.
For many, including me, it was difficult to switch from a technical role to a managerial one. Learning software development and keeping up with the state-of-the-art eats up a lot of time. It's tough letting go of the already acquired knowledge and habits and having other developers take over your previous responsibilities.
Not to mention, management and technical positions demand a different ratio of soft and hard skills. Effort and commitment is required to change old behaviors and tendencies. Some of the old ones will be in direct conflict with the new.
Becoming well organized is a crucial aspect of the transition
Tons of things happen at companies and people get constantly distracted.
I made it a strict habit to write down all the incoming tasks first. That is, even without thinking how to do them and when and who should do them. This goes for my tasks as well as those later assigned to others. Urgent, backlogged, epic, bug, critical, ice boxed and other tasks - they all undergo the same treatment.
Persisting them ensures they stick around no matter what happens. When it comes to management, you never truly know what you'll end up doing throughout the day. What if developers report unexpected technical issues possibly delaying the project, the client decides to rearrange the backlog or someone has a family emergency and is unable to work? You have to act upon such situations and resolve them as they appear. I don't trust my mind will be in the same place it was earlier and before tackling these events and still capable of organizing tasks.
Plus, writing tasks down makes it easier to delegate them later and gives a better sense of the scope of the entire workload.
I learned to approach meetings with the same diligence
It's surprising to notice, how much information is forever lost during team conversations, because we all decided to remember it instead of writing it down. It's perfectly appropriate to ask the team to pause a meeting and make notes. Indeed, it should be important to everyone involved. As a manager, I often share my computer screen at meetings so others can see what was collected with a chance for adjustments and rephrasing.
I noticed this failure to organize quite late after starting my management career. Sadly, many developers don't have such responsibilities while writing software and are not used to managing their own time at the company. It's an easy oversight, because the negative outcomes of this seemingly benign negligence materialize weeks or months later. Suddenly, a bunch of new tasks are added and timelines need revising due to all the omissions. It's a hard lesson to learn, but a valuable one.
I made technology serve me on this journey
Trying to remember anything accurately is a huge mental strain. Allow technology to take over some of this responsibility.
I even went a step further and started publishing information in a couple places. And using reminders to recall it in the future guarantees it won't be shelved forever and never acted upon.
Most PM software includes such a feature. Online calendars have it. Some companies use notifications in Slack to achieve this, too. So, when something happens involving the project in GitHub or Jira or somewhere else, an automatic notification is placed in Slack with a summary. I like writing some of these messages manually for greater effect. Whatever the approach, continuously tracking tasks in some form is highly recommended. The exact form is up for discussion.
As for assigning tasks - always pass them forward
Ex-programmers have an instinct to fix software themselves.
It's very tempting to write code in place of other people. You may think: "I already have the necessary experience and knowledge of the task to do it faster and better than anyone else." or "I want to avoid the long back and forth conversations to transfer my knowledge onto others. They're likely busy anyway and won't do the thing in a long time.".
This strategy is very deceptive. It will be successful for a time. But, once there are too many tasks to handle even for an experienced ex-programmer, chaos ensues followed by quickly shifting responsibilities to other people. Mind you, new responsibilities they had no time to ease into and gradually master. There was no buffer for learning and making mistakes. It's a surefire way to burnout.
For PMs who've never wrote software in their lives professionally, task delegation is a no-brainer. To a technical person, switching their role to a non-technical one - it's something they have to figure out and remind themselves to consistently do.
It's good to have some idea of what other people are doing. But don't take away their job.
Always push work out. The converse doesn't scale. Own experience, motivation and the urge to help have nothing to do with it. Even if the person receiving the work needs onboarding and is initially not as proficient and efficient with it.
If you have no team members who are qualified to do the work, either further develop the ones you have or recruit new team members who are qualified. For many of us, this means getting over our own egos. We often tell ourselves that we must do these tasks, because nobody else can do them as well as we can. But rather than viewing that as self-flattery, we should view this as a failure to develop our teams.
-- Source - HBR
Appreciation for individual effort and careful offsetting of criticism are valuable traits
It's one of my top priorities to be balanced when interacting with others. I guide them to becoming the person I need them to be and publicly appreciate their efforts to do a good job.
An easy thing to forget, is acknowledging people's accomplishments. I did it too sporadically early in my career. A person may find it difficult to know they're doing something well by themselves. Letting them know in a private conversation is fine and I have done it this way. Making it official spreads the word around and also makes the manager feel more organized, personable and fair. It also causes any other opinions, including criticisms, easier to accept.
If all goes well up to here, there's one final boss to face
There's a moment when going gets tough, because the company is riding the wave - getting positive reviews online, receiving more recognition and winning more projects. But it hasn't yet scaled to cover all the work it wants and has the potential to do.
My goal, though, is to delay hiring as much as possible and coordinate the process with the owners of the company (or my direct superiors). Instead, securing the company's future must always be the top priority.
During this intermediary time, existing people are burdened with extra work until more join them and help out.
While uncomfortable, doing the opposite is irresponsible. Preemptive hiring in anticipation for more work down the road is fraught with risk. Having more people on payroll and not enough tasks for them is costly. And someone, the company or new hires, will have to pay the bill. It's best to avoid being in this position in the first place.
Apart from this, the company should aim to hire experienced people who are motivated, creative and can focus on a single task for hours on end. Easier said than done, I know. It's an idealized persona. But from my experience, these people are worth finding and they pay for themselves. In this case, patience is a virtue.
At the first opportunity, I left my comfort zone and switched
It will go better and worse. The goal isn't absolute perfection from the outset. It's a process leading to finding out one's strengths and fixing flaws. Honest want to change and do a good job in the new role is the baseline requirement.
By the way, I've experienced people balance project management and software development responsibilities. These people are few and far between. It is confusing and mentally draining for many, including myself. But some do have the fortitude to withstand the intensity.
A tech leadership role tends to be somewhere in between the two. Following this path reduces the range of soft and hard skills expected but, quite often, also the influence on the project.
After years of switching roles, I still cannot conclude whether going through such a fundamental change is beneficial for a company to support. But it surely is eye-opening for the person taking the plunge.