It’s your career etc. but as a well meaning random stranger:
>> I know a full rewrite is necessary
Rewrite it in rust! /s
You’re most likely focussing on the wrong thing here. The tech doesn’t matter. It’s a business, this bit matters:
>> this code generates more than 20 million dollars a year of revenue
You need to be able to quantify which lines of code you’re going to change to increase that 20 number to something higher, or at the very least, increase the amount of that the business gets to keep rather than burn on costs.
This might sound like a hard problem at first glance but it’s really not.
>> This business unit has a pretty aggressive roadmap
This is a positive. To be clear the worst case is an apathetic business unit. This is huge, you’re already ahead. People want things from you so you’re free to exchange what they want for what you need. Think of other business units as part of your workforce, what can they do to help you?
>> management and HQ has no real understanding of these blockers
Yeah that’s the way it is and it’s totally ok, management doesn’t fully appreciate the blockers impacting the HR unit or plant maintenance or purchasing or customer service or etc etc but they DO NEED to know from you the problems you can see that they care about.
That means issues about how code quality are problematic are out of scope but informing management that your team are going to continue to be slow for now are in scope.
Issues about developing in production are out. Issues about your working practice is unsafe and we have a high risk of breaking the revenue stream unexpectedly over the coming weeks and months, that’s in scope for being communicated. At the same time, take them through the high level of your mitigation plan. Use neon lights to point out the levers they can pull for you, e.g. we need SAAS product X at a cost of $$$ for the next year to help us deliver Y $$$ in return.
For every strategic piece of work you line up, be clear on how many $$$ it’s going to unlock.
Be clear on how you personally can fail here. Transparency and doing what you say you will go a long way.
Practice saying no.
You’re an unknown quantity to them so get ahead of that. For example, make it so you’re always first to tell the other units when the product has broken for a customer, rather than customer service telling you about a support ticket that just came in.
>> I know a full rewrite is necessary
Rewrite it in rust! /s
You’re most likely focussing on the wrong thing here. The tech doesn’t matter. It’s a business, this bit matters:
>> this code generates more than 20 million dollars a year of revenue
You need to be able to quantify which lines of code you’re going to change to increase that 20 number to something higher, or at the very least, increase the amount of that the business gets to keep rather than burn on costs.
This might sound like a hard problem at first glance but it’s really not.
>> This business unit has a pretty aggressive roadmap
This is a positive. To be clear the worst case is an apathetic business unit. This is huge, you’re already ahead. People want things from you so you’re free to exchange what they want for what you need. Think of other business units as part of your workforce, what can they do to help you?
>> management and HQ has no real understanding of these blockers
Yeah that’s the way it is and it’s totally ok, management doesn’t fully appreciate the blockers impacting the HR unit or plant maintenance or purchasing or customer service or etc etc but they DO NEED to know from you the problems you can see that they care about.
That means issues about how code quality are problematic are out of scope but informing management that your team are going to continue to be slow for now are in scope.
Issues about developing in production are out. Issues about your working practice is unsafe and we have a high risk of breaking the revenue stream unexpectedly over the coming weeks and months, that’s in scope for being communicated. At the same time, take them through the high level of your mitigation plan. Use neon lights to point out the levers they can pull for you, e.g. we need SAAS product X at a cost of $$$ for the next year to help us deliver Y $$$ in return.
For every strategic piece of work you line up, be clear on how many $$$ it’s going to unlock.
Be clear on how you personally can fail here. Transparency and doing what you say you will go a long way.
Practice saying no.
You’re an unknown quantity to them so get ahead of that. For example, make it so you’re always first to tell the other units when the product has broken for a customer, rather than customer service telling you about a support ticket that just came in.