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, head of data engineering, and most recently, head of cloud operations.

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 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. It also makes it easier for both of us to work on your career development.

I consider what you tell me on 1-1s as confidential, unless I am legally obliged to act on it, 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 it comes to receiving feedback, I 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 to our customers and users. 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 and competence. 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 (being sarcastic when it's not the time or place), 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 EUR every month for a year, starting now (that is: 100 × 12 = 1,200 EUR), or would you delay for 4 months but have a better solution which earns you 130 EUR per month for the remaining eight months (130 × 8 = 1,040 EUR)? It’s clear that starting to get money sooner - in many cases - beats a delayed solution. Moreover, we can release the first solution ("100 EUR") and improve it after the first few months once it proves its worth, so the "better" (130 EUR) solution will never catch up. This is the idea behind the incremental delivery.

This concept 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 sooner.

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