@radekmieAbout · Blog · GitHub · RSS · Timeline

By Radosław Miernik · Published on 31 October 2025 · Comment on Reddit

Table of contents

• Intro
• You Don’t Know Everything
• You Should Care
• You Are a Developer
• Closing thoughts

Intro

As the year slowly comes to an end, many companies – including the one I currently work for – are reviewing their budgets and planning the upcoming year. In my experience, such meetings happen on the so-called “C-Level”, i.e., among the people responsible for each department of the company1.

As a Head of Engineering, I’m attending these, too. Of course, I’m there mostly because of the personnel and operational costs of the developers (including their salaries, as well as hosting or 3rd party tools), but that’s the rather boring part. (And heavily covered with an NDA.)

Today, I want to share how developers (or other strictly technical roles) can be of help in these meetings. Keep in mind that your mileage may vary, and I don’t know your company’s culture.

You Don’t Know Everything

Obvious, I know. But it comes in two flavors: you assume something but act like you know it, or you have no idea and stay shut. The former is riskier, as it can influence others’ decisions – in the end, you are in this meeting, so they can trust you, right? The latter is seemingly safe, but it may cost you a lot of time to unwind the uninformed decisions you all made2.

I know your impostor syndrome stops you from asking novice-level questions, but if you don’t know what the difference is between blarp and blurp in your Marketing team’s goals, just ask them. First of all, you may not be the only one not knowing that, but the only one who asks. Secondly, different people may have different understandings of the difference in this context, especially if it relates to more than one team3.

Asking too many questions is not good either, but since all of this is vague and subjective, I can say no one does a good job here. Just make sure that the next time some decision includes you or your team in any way, make sure that you have a common understanding of its consequences.

You Should Care

A seemingly unrelated to you topic is being discussed, so you decide to scroll through your social media of choice answer emails? My take is that on this level, everything is relevant to everyone. There are probably just a few more people there, but their performance will have an impact on your work, even if you don’t interact with them directly (e.g., by contributing more to the budget).

Maybe you already have a direct incentive, like shares, or ESOP (you should); in that case, the greater good means something tangible (even if it’s just a distant dream now). If not, there’s your team – the reason you are in this room.

Can you secure more budget for experiments or personal development? Great, do that! Maybe you could prioritize development experience more? Awesome! I know it may feel like you’re there to get your energy sucked for stakeholders’ benefit, but at least try to get the best out of it.

You Are a Developer

(Or just pretend for the sake of this paragraph.) The average person who makes a living out of programming has a different skill set than someone doing sales, and that’s fine. There’s a high chance you can make rough calculations in your head on the spot, unlike the others in the room4, so do it. Sure, you may not be precise, but it’s enough to spot gaps in the numbers.

Another “superpower” you probably bring to the table is a tendency for formal definitions. At the beginning, it may be hard to accept that on this level most topics are vague (“Not everything is 0s and 1s, Radek!”), but pointing out that your definition of “usually” may be different from someone else’s is good.

And yes, your point of view is skewed by it. You will have a different take on AI, team motivation, work automation, or “high standards”. (Not that your opinion has to be different, but your arguments will.) Don’t be afraid to share and explore the differences during the discussions, as otherwise the mismatch of expectations may lead to your – or even worse – your team’s burnout.

Closing thoughts

Wow, I was rambling for 12 paragraphs now! I hoped to prepare something useful for people in a similar position, but in hindsight, I should have known it would be yet another self-reflection post. Or maybe it’s a message in a bottle for the next year’s planning.

One month left to finalize the budget, gotta go!

1

We’re not a big company, so we prefer “Head of X” titles to “CxO” ones. It’s also a matter of company culture and your personal prejudice. For me, a “Head of Engineering” and “Chief Technical Officer” at a small company can have the exact same responsibilities, but the latter sounds… Significantly less technical but far more manager-ish.

2

If it happens in the same meeting, it “only” takes a few minutes or hours. But if it will reappear a few months later, then congratulations: you just created a hole in the budget.

3

A good example is a definition of when a new feature is considered “ready”. For a person implementing it, it’s most likely as soon as the code is merged or released. But for another, it may need to wait for a release note, knowledge base article, and a dedicated marketing campaign.

4

Except for the finance people; they live in Excel, breathe numbers, and bleed in formulas. But that’s a standard among highly specialized roles.