Episode 48: Engineering Culture from Zero to Scale – Krzysztof Ras

Welcome back to SphereCast, Sphere's biweekly conversations with entrepreneurs, business, and tech leaders, offering practical advice on technology, innovation, and scaling.

I'm your host, Adin Heric, and today we're diving into a topic every growing tech company eventually faces: how to build and scale an engineering culture that actually works.

Our guest today has done just that, leading teams from startup size to scale-up stage across the Middle East and Asia, including time spent growing teams in both Arabia and China.

We'll talk about what it takes to set a cultural foundation from day one, how the first 100 days shape long-term success, and how leadership shifts as teams grow from a handful of engineers to large distributed organizations.

Chris, welcome to SphereCast. Great to have you, of course. Could you please introduce yourself a little bit to our audience?

Sure. Hi, Adin. It's great to connect.

My name is Krzysztof Ras. I am a software engineer by heart and by education. However, for the last two decades, I've been building and scaling high-performing engineering organizations, including launching two major tech hubs in Poland, leading multiple product teams across EMEA, and driving large-scale transformation programs in the financial space.

My focus is on engineering strategy, organizational design, delivering results at scale, but mostly strong engineering culture.

For the past 3 years—last 3 years I spent in the Middle East, working on launching first digital banking experience in Riyadh, Saudi Arabia, and and one more initiative.

I'm exploring senior engineering executive roles where I can combine strategic leadership with hands-on operational impact, so ideally in organizations looking to scale, modernize, or accelerate product delivery.

Yeah, that's me.

Cool. Great to have you here, Chris. So, you said two things. Let me just go with the first question there. You know, you have built engineering teams from the ground up. So, what do you think when you go back to the very first phase during that time, what does building culture mean before, you know, the team even exists?

Got it. To me, building culture before the team exists is about deciding what you will tolerate and reward, then making this explicit in the decisions you make today. Because culture isn't posters or one-page values doc, right? It's the pattern of decisions you take about hiring, the first product priorities, how you communicate, and who you trust with responsibility.

So, when I started teams from zero, I focused on three things up front: first, clear mission, why this team matters; a few non-negotiable working norms, like psychological safety, ownership, transparent decisions; and the hiring bar.

So, those three act like a cultural seed. The mission attracts the right people, the norms shape day-to-day behavior, and the hiring bar ensures that each new hire tends to reinforce, not dilute, the founding culture.

I will give you a concrete practice I used before. So, before posting the first role, I wrote the first 90-day charter, so what the team must accomplish in its first 3 months and the behaviors that will get them there. This charter becomes a filter during interviews and in the first onboarding conversations. And that worked pretty well for me in the past.

That's that's that's some great insights, yeah, definitely. I I can definitely relate on both sides, being the candidate, so to say, for for a role, but also being a manager hiring for that role, right? So, you want to eliminate and attract, you know, the best profiles of course for that role. Makes sense.

So, you said 90 days. Let me go with 100 days. So, what do you focus on the first 100 days, you know, when you come in? And you know, is it about hiring? Is it about values? It's about procedure or delivery? You know, because, you know, it goes hand in hand and you need to find the right balance, of course, there. But, you know, what is it the first 100 days, your main focus?

Yeah, that's a very good question. So, I would say all the above you mentioned, but sequenced. So, my mental checklist for the first 100 days is listen, stabilize, deliver, and scale.

So, first 30 days, you listen and learn. You talk to the stakeholders, customers, and any early hires. You map dependencies and risks. I use this time to clarify success criteria with the business or with my boss, but basically aligning expectations with my manager. So, I put an explicit alignment with boss step into onboarding so that we are on the same page, right?

Next 30 days, so 30 up to 60, stabilize. So, hire a few critical roles, if needed, select one or two engineering rituals, that can be code reviews, sprint demos, CI pipeline, whatever, and ensure a reproducible onboarding flow. So, basically, it's about establishing the four or five metrics that will that that team will watch, right?

Next phase, I would call accelerating or delivery. So, basically, the last 30, 40 days is about delivering a clear, visible win, something that builds credibility and demonstrates how you work. Then start creating repeatable processes for hiring, onboarding, and architectural decisions.

It's very important to say this: you can't do everything in the first 100 days, so you need to prioritize things that create leverage. Let's say one great hire, one automated deployment pipeline, one reliable release cadence, whatever it is. But basically, you need to have this and you need to build your community. So, basically, all in all, you need to get this positive feedback from all over the place to be successful.

All right. Yeah, definitely. I definitely like the the alignment statement that you said with with your boss. I'm I'm I'm going to I'm going to keep that one in mind, honestly, because I think it's very crucial, right? I think also that companies, when they're hiring, they have, you know, a mission for that role, so to say, but then the person who comes may have actually seen also some other topics, you know, that can be put on the to-do which have better leverage, as you said. So, I think I think, you know, aligning that pre, so to say, contract, and then then the real execution contract that you also see, makes makes definitely sense, yeah. Definitely.

Yeah. If I may just add one recommendation to you and to podcast, you know, audience, what worked really, really well for me is the book called The First 90 Days by Michael Watkins. It's a, I would call it, a, you know, bulletproof guide that helped me at least couple of times in my life when I was entering a new role. So, if you have a chance, please do take a look at this at this book, especially if you're stepping into your new role. It can be new organization, but maybe a new role within your organization. Worth reading, 100%.

Thank you for that. I'll definitely link that in our description. Thanks thanks for that.

So, when we talk about culture, in the early days culture can't just be written in a job description, on a slide, it's defined by daily behavior, right? So, how do you make sure that the team lives you know, lives the the values, not just talks about them? I think this is not just for the, you know, new roles that you come in, this is for everybody managing and and you know, want to make sure that the values are lived.

Sure. Okay. Let me think for a while. I mean, I completely agree. Culture isn't just about what's written on a slide or in a handbook, but it's something that comes to life through daily team behaviors, interactions, and decisions. And to ensure the culture thrives and aligns with the value stated, I especially—I mean, especially in organizations as globally diverse as I've been working I've been working at, my my approach is couple of items.

First, clear communication and alignment. Early on, it's crucial to translate the company's stated values, like ownership, collaboration, innovation, into practical, actionable behaviors. For example, if ownership is key, I would work with team leads to set clear expectations around accountability and driving initiatives independently. I would also hold regular check-ins to align with broader vision.

Second, and maybe this is more important, lead by example. As leaders, we set the tone of behavior within the team. Whether it's actively embodying collaboration by building bridges across departments or celebrating innovative ideas, I believe that these small intentional actions signal that culture starts at the top and you are the ambassador of of the culture.

Third, I would say I would say adapt for diversity. So, I would adopt an inclusive approach that accounts for cultural nuances. And I'm saying this based on my recent experience in the Middle East where I had team all over the all over the MENA region, but also teams in China. And it's super important to recognize and tailor the communication for local norms while ensuring they align with the company overarching culture.

One last thing, it's feedback loops. It's feedback loops, finally. So, creating open channels for feedback is central by implementing tools like pulse surveys or anonymous feedback boards. I would ensure team members feel empowered to share honest opinions on alignment with values.

Great. Great points here. We'll we'll definitely go a little bit deeper in your experience of course with MENA and and China later on, but before that, would love to understand from you how you balanced between speed and stability, you know? So, every every startup struggles between, you know, building fast or building right, right? So, how do you, you know, balance engineering disciplined things like, you know, clean architecture, testing, and process with the urgency to ship fast, right? So, it's it's a balancing act. And maybe if you also can give have some real-life examples as well.

Okay. So, think in terms of risk-managed speed. So, the question isn't about speed versus discipline, it's where the biggest risks lie and what discipline buys you the most. So, so, what I believe in is, I mean, in early days, to I prefer simple, well-tested building blocks for critical paths, the parts that which means that the parts that touch many users or hold state.

For experimental features, I favor fast, reversible patterns, so feature flags, short-lived branches. So, we basically build something, test it, and decide if we continue or not. Certainly, investing early in automation. Unfortunately, too often I've seen I've I've joined organizations which lagged on this. I mean, my entire experience in in the MENA region was I mean, when I joined, there was not there was very little on the test automation, and this can be a a great leverage, right?

What else? Yeah, I mean, like I say, layered, risk-based approach, so, you know, with the core systems, these need to be stable, resilient, and fully tested before iterations. Experimentation areas, where speed-to-market is critical, I encourage building MVPs that can be refined iteratively based on feedback. And on infra enhancements, this work concurrently to support future growth without blocking immediate deliverables.

So, this is what I am calling a balance, you know? So, what I tell what I tell teams is ship to learn, but ship in a way you can confidentially iterate on. Sorry, confidently iterate on. So, basically, like I say, feature flags, canary releases, automated tests that let you be bold without burning the house down.

Makes sense. Makes sense, Chris. You mentioned before Middle East, so you have built teams in the Middle East, a you know, a region where ecosystems are growing fast, but operate differently, definitely, from the West. So, what unique leadership lessons did you take from that experience?

That's a great question, because I learned it in a hard way. Yeah, the Middle East taught me two big lessons: patience in relationship building, and a huge opportunity for bespoke leadership.

Many organizations are growing fast, but decision-making and incentives can be shaped by local corporate culture and stakeholder dynamics. That means progress often depends as much on trusted relationship was as on the technical plans. And this is what I'm saying I've learned it in the hard way, because I've been struggling for the first couple of months because I did not know, I did not recognize that those relationships matter the most.

I mean, I was there as a VP of engineering, working closely with the C-level and even the board sometimes. However, it means nothing if you don't have if you don't have, let's call it, FaceTime and stakeholder mapping. So, a quick technical decision can be stalled by an unexpected stakeholder which you even didn't recognize. So, spotting that early and getting a small, informal alignment saves weeks.

I also learned to tailor communication, super important. So, more context and clarity up front and explicit written decisions that travel across language and hierarchy differences.

One last item, because the ecosystem there is still maturing, there's an opportunity to create career paths and training programs, like internships, mentorships, that accelerate talent growth. I treated that as a part of my cultural mandate to help the region grow with while building the product.

Great. Great. So, could you maybe elaborate a little bit more, Chris, on the stakeholders that you didn't even had on your radar? So, could you could you give—I mean, you don't have to go too much in the detail telling who the person is, but, you know, just to understand in your example, what what was the blocker there that you didn't see coming?

Let me think for a while, because I would love to give you a specific specific example.

So, when I joined the organization as a VP of engineering in in Middle East, one of my key goals was to fast-track product delivery while scaling our team and infrastructure. However, I quickly encountered challenges in decision-making process that weren't immediately visible.

For instance, I overlooked the influence of a senior stakeholder responsible for government partnerships. This person wasn't part of our direct engineering discussion, he was not even on the product, he was more like a compliance. But he held significant sway over contractual and compliance matters, and their input was required to move ahead. Yet, due to a lack of prior engagement or informal alignment, the project was paused.

And that experience taught me the strong need for mapping not just my immediate collaborators, but decision-make the decision-makers and the broader landscape of indirect influence influencers. The impact of that lesson was immense. So, moving forward, I regularly conducted informal stakeholder analysis during the planning phases and implemented proactive communication tailored to local dynamics. FaceTime, tea time, explicit documentation, and frequent alignment check-ins became non-negotiable in my approach.

Yeah. Yeah. I heard that before, definitely. So so, yeah, makes definitely sense. Good.

Let's go basically with the same question, Chris, but then for China, right? So, you have experience also China. How is that different than EMEA and of course the Western the Western working culture?

Yeah. I mean, China is a masterclass in execution velocity and data-driven decision-making. The environment taught me to couple speed with tight feedback loops: ship small, measure, and iterate aggressively. It also reinforced the value of operational rigor, lots of rapid experiments, but each one measured with clear metrics.

What is more important is the leadership. It also taught me about adapting to ambiguity and being decisive. So, when timelines are aggressive, you can't wait for per- perfect consensus, you need quick hypothesis, aligned ownership, and cadences that forces resolution.

Yeah, culturally, the experience reminded me that you must watch local working norms while still protecting the elements of culture you believe in. For example, pairing fast execution with explicit rituals for quality and learning.

Good one. Yeah. All right.

Let's go to to the next question, you know. I think you touched base also while while you were saying about your bullet points, what you have learned, but managing cross, you know, multiple languages, time zones, cultural expectations, is a challenge for for any leader. How do you maintain shared values and trust when your teams are distributed globally, and especially when it's of course then, you know, virtually as well?

Oh, yeah, that's that's a good one. So, you know, managing multiple languages, time zones, cultures, and expectations definitely a complex challenge, but in this, it's an area I've developed a strong expertise in over over the years. So, for example, in one of my previous roles as a VP of engineering overseeing teams spread across the Middle East, but also Europe and Asia, the first step was to create a unified framework for alignment. That included that included mapping communication preferences across cultures, establishing clear rituals for sharing feedback, and structuring workflows that accommodated different time zones.

So, I learned to foster trust and collaboration by ensuring asynchronous work and synchronous touch points that were very highly purposeful.

So, a key lesson I carried forward was that cultural nuances genuinely shaped the dynamics. For instance, in Europe, direct feedback and autonomy are often appreciated, while in Asia and and in China, decisions are sometimes influenced by hierarchies and indirect communication styles. So, my balance was to my approach was to balance this cultural sensitivity with a unified engineering culture rooted in transparency, ownership, and innovation.

Me, personally, I believe to trust, autonomy, and ownership. And believe me, China, like I said before, is a powerhouse in execution. However, this hierarchical, let's say, relationship exists, which also I learned in the hard way.

And also, and also, if I may, I would love to recommend another book that was very, very helpful for me, because I can say that for my first, let's say, adventure in the Middle East, I was not prepared, but for the second one, I was, because I read the book. It's it's called The Culture Map by—

The Culture Map.

Yeah, by by—I forgot the name right now. Erin Meyer. Erin Meyer, who is the former CHRO, so Chief HR Officer at Netflix. She wrote a great book about all those cultural differences, nuances, and it helped me a lot to deal with my China team.

That's good. That's good, and thanks for sharing. We will definitely also link that one.

So, there is of course new new tech on the block, AI. So, with AI reshaping development, how do you think engineering culture should evolve? And are there ways AI can strengthen or potentially weaken team collaboration and innovation? And of course, if you use it already, you know, please let me know what kind of example you can share with us.

Sure. Well, you know, AI is a powerful productivity multiplier, but it's just a tool, and the culture must adapt intentionally.

Where it helps: so, reduce mechanical work, like, I don't know, tests, docs, scaffolding code; freeing engineers for higher-leverage tasks, like system design and domain thinking; it helps to improve onboarding with AI-generated personalized learning paths and codebase walkthroughs; it can surface knowledge by summarizing PRs, incidents, and discussions, so it makes the async work more efficient.

However, it can also hurt. So, over-reliance on generated code without understanding leads to technical debt and loss of craft. In fact, and I will tell you more about it in a minute, when I introduced Copilot AI in my last organization, the productivity drops dropped for about two iterations, which is 4 weeks, by 25% because engineers were spending too much time on not rewriting, but also reviewing the code.

So, like I say, if used to optimize for velocity only, it can erode code quality and collective ownership. So, speaking about culture, what I recommend is teach everyone to prompt and verify, so it requires explainability and tests for generated code. Next, keep code reviews and design reviews as cultural anchors. AI should assist, not replace human judgment. Third would be establish UAE usage—sorry, AI usage norms, so what's okay to automerge, what needs senior review, how to credit AI-assisted work.

And yeah, use AI to free time for mentorship, architecture conversations, and cross-training, that's where culture and innovation thrive.

Great examples there. Thank you for sharing, Chris.

You know, if you had to summarize your biggest lessons from building engineering culture across different geographical parts of the world and growth stages, what would that be, would you say? It's a it's a it's a it's a big question, I know.

Yeah. Culture is a product you ship continuously, so to say. So, it requires the same product mindset: define the experience, measure measure it, iterate, and decide hard trade-offs. Be intentional early. The defaults you set when you are small compound as as you scale.

So, if I were to just think on high level, I would say alignment and shared purpose, adaptability to cultural nuances, and probably fostering innovation with the right environment. So, things like culture of trust, curiosity, ownership drives innovation.

As someone passionate about, you know, embedding emerging technologies like AI, I emphasize collaboration over micromanagement and prioritized mentoring engineers to confidentially take risks. So, yeah, yeah, I think that's it.

All right. Well, that's a good one to to wrap it up, I think, Chris. So, I just want to thank you, and of course, from Sphere as well, for sharing your experience and perspective, especially, you know, scaling in different cultures and scaling from zero to 200, so to say. So, thank you very much for taking the time out of your day, Chris, and and, you know, sharing your experiences. I think it's definitely very valuable for our audience. Yeah, and I hope I I see you again in another episode, Chris.

Likewise, and thank you for having me, Adin.

Sure, sure. Have a good one, Chris.

You too.

Thank you for sharing your experience and perspective, from the first 100 days to scaling teams across the world.

For our listeners, if you're building or leading tech a tech team, there is a lot to take away here from the importance of setting cultural foundation early to the nuance of leading across borders.

Thanks for tuning in to SphereCast. Don't forget to follow us for more stories on technology, leadership, and innovation.