What is this document about? (9-minutes read)

This readme is mostly for colleagues who (directly or indirectly) report to me and want to learn more about how I work.

We all change, so I’ll do my best to keep this document up to date.

I’ve outlined a few key things you can expect from me here. Of course, this isn’t a replacement for getting to know each other in person and working together—this document is here only to help us a bit in the beginning.

First code in 1996...

I wrote my first useful code and got some small compensation for it back in 1996, when I was in high school. The app calculated the distribution of static weight on a load-bearing beam to predict its breaking point. It was built in QBasic and ran on MS-DOS.

After earning a master’s degree in electrical engineering, I started as a software engineer in telecommunications, focused on systems integration. Since then, I’ve been a solution architect, engineering manager, product manager, and most recently, head of infrastructure (data engineering before that).

I still like to code a bit in my spare time on my hobby projects, mostly in Node.js and Python.

How can I support you as your manager?

First and foremost, please feel free to talk to me whenever you need to. I’ll make the time—just reach out.

As your direct or indirect manager, I’ll check in from time to time about your ambitions and what you’d like to get out of work. But you don’t need to wait for me to bring it up—feel free to let me know whenever you’d like to chat about it. A big part of my role is pairing the right people and their motives with the relevant tasks. We can tweak some of the team’s workload to match your interests, though we’ll always need to prioritize business goals—that’s how we all earn our salaries.

Also, you can always count on me to clarify our priorities.

Our one-on-one meetings

I hold one-on-one meetings with colleagues who report to me, directly or indirectly. The main purpose of these 1:1s is to share feedback and discuss how we can support each other. It’s a two-way conversation.

One-on-ones are as much yours as they are mine—maybe even more yours. Use them to share your ideas, aspirations, and thoughts. Ask for my help, give me feedback, or bring up anything else on your mind. If you have any ideas about what we can improve, change, etc. please let me know.

I usually have a document that I share only between you and me where we can keep private notes from our 1:1s. My advice is to add topics of the conversation in this document before each 1:1, so we can keep the track.

I consider what you tell me on 1-1s as confidential, unless I am legally obliged to act on it, of course, or if we agree to share some topic with our colleagues.

Continuous feedback

The whole point of feedback is to help each other achieve our best results. It’s a two-way street, not just something that flows from manager to team member.

I’ve worked with many sorts of personalities and communication styles over the years. When we start working together, I’ll ask how you like to receive feedback and stick to that. I welcome your feedback to me and prefer it direct, timely, attached to our goals, and specific (backed by examples/data).

There’s a handy framework for giving feedback called "Situation, Behavior, Impact" (SBI) that I recommend checking out:

https://www.ccl.org/articles/leading-effectively-articles/closing-the-gap-between-intent-vs-impact-sbii/

Ownership, autonomy, and trust

I highly value an ownership mentality. Ownership is about not waiting for someone to tell you how to do something—instead, you try proactively to figure it out yourself (by asking or researching) and make it happen. Ownership means you care, you don’t need constant handholding or a "personal assistant", and you lead.

Ownership isn’t tied to seniority. I’ve worked with junior engineers who showed incredible ownership and took initiative. Every one of them has grown into an excellent career.

Most people—including me—don’t enjoy being micromanaged. We do our best work when we have autonomy and when we care about what we are doing. That goes hand in hand with trust—if we trust each other to do the right thing, we can be incredibly effective. One of my goals as your manager is to give you the autonomy to handle your projects with ownership.

I also work to optimize various processes in our teams. But those processes won’t work without your input, timely updates, and proactive approach—all part of trust. Our teams will collaborate to keep improving how we work, and your ideas for boosting efficiency are essential.

Ideas, plans, and actions

Our company can only get value (profit) from projects that we release to production. Ideas and plans don’t contribute to the business unless we deliver them in production. Good ideas are plentiful, but good execution is often a bottleneck. Part of my job is ensuring our teams focus on efforts that benefit the company (in line with leadership’s direction) and stick to our plans. I am also a big fan of simplifying things and will always try to do it.

Working in a team

Engineering attracts smart, resourceful people. But as technology gets more complex, teamwork becomes more critical and outshines individual talent. A skilled team that works well together will always beat a dysfunctional group of brilliant genius engineers.

The biggest hurdle to team efficiency is “ego battles.” Things like interrupting each other, playing status games, not giving others room to speak, dismissing ideas out of hand, or debating just to win instead of finding the best solution—these habits slow us down. Part of my job is to maintain a strong team culture.

Timing beats perfectionism

I always think about what a day, week, or month of our team’s time costs. Every wasted moment (not used to add value) hits the company’s bottom line. Delays eat up the budget, so let’s invest our time smartly.

Here’s an example: Would you rather take 100 euros every month for a year, starting now (that is: 100 × 12 = 1,200 EUR), or would you delay for 4 months but earn 130 euros per month for the remaining eight months (130 × 8 = 1,040 EUR)? It’s clear that starting sooner, even with 30% less profit per month, beats a delayed solution even if it's 30% better. Moreover, we can improve the first solution after the first few months once it proves its worth—that’s incremental delivery.

This shows a “sense of urgency” (or agile mindset). It’s really about avoiding perfectionism and overthinking decisions, and delivering something solid enough that makes a difference and adds value.

Thanks for reading!

I’m looking forward to getting to know you through our working together, let's catch up!

If you’ve got your own readme, please share it with me—I’d love to take a look.

Best,
Andreja