Edition Zero: The Beginning
I am a people-centric Technical Program Manager. This newsletter is different because:
It shows real-life examples from my career, which differs from the general TPM profile.
It cuts the general knowledge topic you could discover in blogs and newsletters created by much better TPMs.
It shows the new things I learn almost every week.
It contains inspiration from the Heavy Metal music domain.
It examines topics like Mental Health, insecurity, the creativity lock, and more, which are part of the TPM world, but only a few colleagues are open to discussing this.
I am also reachable on various channels and love helping people. Some of them allowed me to share the problems they had and what I advised them.
Edition Zero
For edition 0, I will start by sharing two articles I wrote on my blog. I bet you have never visited it, so I can claim this is unique content. :)
Problem 1: How do you estimate items too early to be estimated?
As a Program Manager, I must facilitate estimates for items too early to be estimated in almost every company I work with.
Let's not kid ourselves; estimates are needed in the modern business world, especially when you release your first version of a complex product and hit the right product/market fit on time. Of course, you could argue that the modern Agile method doesn't work with deadlines, but I want to stop you here and say this is incorrect.
You can still deliver sprint after sprint, but releasing it to the customers for the first time in the complicated business situation where we live and operate needs a deadline to plan all the activities related to a product release.
Set the stage
Problem definitions:
Estimating in a very complex environment is always incorrect. The more prolonged the period, the more significant the error margin is.
Often, somebody else estimates the engineering work based on a gut feeling and the wrong level of granularity.
We don't know what we don't know, but when we know what we didn't know, we don't do anything with the knowledge.
Let's get practical.
Imagine we have a team of 3 engineering teams with a mission to build a helpful COVID-19 vaccination website so anyone in a specific area could book a slot for them and empower the medical staff to serve them quickly. It's essential to have this product built by November 5th to prevent the mass gathering of people wanting to be vaccinated and to reduce the risk of contamination during the long waiting times. The expected date for this event was taken from the national health body.
Problem 2: Deliver a product with an impossible timeline
I will share a real problem and how we solved it despite all the opinions and facts that we will fail. You could learn something from the following few paragraphs.
We were in a situation to deliver a product with an impossible timeline because of many business-related reasons.
For an easy calculation, let's say our team capacity was around 100 SP, and we got four sprints to produce a stable product version.
At this point, we got around 500 SP worth in the backlog + a good amount of unestimated stories + a few new features that we knew would come to our team in a sprint or so.
Let's remember the time allocation for fixing bugs, which in the past was separate from our capacity for obvious reasons.
So we had at least two times more SP that we could deliver. How do we solve this?
You can go ahead and explore the complete solutions here.
AMA
I come from a direct culture. How do I communicate so that people understand what I am trying to tell them?
I received this question via e-mail.
The cold dish:
Peter: I come from a very "direct" culture and am often seen as rude while communicating with others. Once, someone also reported me to HR. How would you be able to solve this?
My recipe:
Just to let you know, you hit the spot. I had the same experience since I come from the Balkans, and how we express ourselves can sometimes qualify as "inappropriate for business."
This is what I did; it helped me communicate well. Also, the feedback I received confirmed that I am moving in the right direction.
Ingredient 1: Give more context.
Before saying to someone that they suck or the process in B.S., take a step back and think about what you are trying to achieve. You don't want to offend your business peers, but helping them see something they don't could make your working lives much more manageable.
Could you pause and then try to give context first? What are you trying to do, and why do you think it's not working?
Instead of this:
WTF?!? Your logs are broken, and because of that, we are failing the deployment. Fix your *** now.
Try something like this:
Hey Jamie, I am trying to make the release process faster, and I saw that your application logs are strangely formatted. Please help me understand why that is so I don't bother you in the future.
Ingredient 2: Be careful
It takes some time to rephrase your good intentions in something that would be constructive and understood correctly by others.
Some people will "meet you in the middle" and adapt to your style while you are adjusting to theirs.
Some people would not. Choose your fight wisely. If you talk with some high-level stakeholders, you should adapt to their style instead of waiting for them to do some steps.
Here is an excellent article on the topic.
Why heavy metal?
If you are a fan, you probably know that heavy metal music has one of the most magnificent lyrics of all the other styles. Feeling the energy and the wisdom that this music holds helped me overcome some of my troubles and inspired me to look at my challenges differently.
I'll give you an example: As an RTE (Release Train Engineer), one of the songs I constantly listened to was Ozzy Osbourne's "Crazy Train." The lyrics are pretty applicable to my work, "I'm going off the rails on a crazy train," but the rest of the text also has great value.
Enjoy reading my newsletter and listening to your favorite heavy metal bands. I'd love to hear about them. Please share a link with me.