I recently spent an hour coaching a backend engineer during an interview. He spent most of his time drawing boxes on a whiteboard instead of asking questions to validate his assumptions. I asked him how he would build a set of B2B SaaS APIs for a specific use case and he jumped straight into the design. He did not ask about the pricing model. He did not ask about the expected API volume per customer. He did not ask about the timeline to ship the first version.
He started explaining a solution to a problem he had not fully defined yet.
This is a recurring theme in our industry. We have created an environment where engineers are rewarded for knowing the what but not the why. They can tell you how to set up a Kubernetes cluster but they cannot tell you if that cluster is the right tool for the business goal. In these cases, engineers optimise for “Resume-Driven-Development,” where they use tech just to add it to their resume. This results in projects that have more than twenty microservices and zero users in production.
At One2N, we wanted to fix this behaviour at the root. We realised that the only way to do this is to change how engineers learn, practice and make decisions every day. We do not just want people who know tools. We want practitioners who start from the problem, understand the constraints and then design the solution. Hence, we built Prayogshala.
Prayogshala is our internal engineering laboratory where teams build real-world POCs and turn these into reusable artifacts for client work.
Principal-Led Mentorship and the "CHOTU" Model
When our engineers aren't working on a client engagement, they work in the lab. But this isn't self-study where someone is left alone with a Udemy login. It is a guided apprenticeship led by our Principal SRE, Saurabh Hirani.
Saurabh is who we call CHOTU - our Chief Head of Talent Upskilling. The title is lighthearted but the work is rigorous. Saurabh brings fifteen years of experience building and scaling systems. He doesn't give lectures. Instead, he identifies POCs that be converted into reusable artifacts based on our work at portfolio companies of PeakXV, Accel and Lightspeed.
When an engineer picks up a POC in the Prayogshala, they are expected to own it end to end. If they are looking at OpenTelemetry, VictoriaMetrics, or ClickHouse, they are doing much more than just a simple getting started guide. They are building a functional system that has to stand up to Saurabh’s scrutiny.
He acts as the most difficult customer an engineer will ever face. He evaluates their code and also focuses on whether the code is maintainable. He will push the team to explain the trade-offs. For example, he will ask why they chose a particular data model or how their solution improves application performance. In my experience, this friction and the dialogue where an engineer has to explain “why” and “why not this” is where real growth happens.
Moving Beyond "Hello World"
The problem with most engineering training is that it stops at the Hello World stage. You follow a tutorial, the code works and you move on. But you haven't seen how your solution behaves during a network latency spike or when the data volume exceeds the memory limits.
In Prayogshala, we ask engineers to explore these “edge cases” and design their solution accordingly.
We get the engineers to take up POCs on technologies that actually matter to the business. We evaluate Istio for service mesh implementation, Kubecost for cloud cost optimisations and Warpbuild to see if we can reduce the build time for a giant monorepo. We investigate Keycloak for identity because we know how costly AWS Cognito gets in production.
The goal is to prove the solution and write about the trade-offs. Once an engineer finishes a POC, they have to deliver a Tech Session internally. This is the ultimate test of understanding. The goal is to explain your choices and answer “why” and “why not” to your peers. If you can’t do that, you’ve just followed a tutorial and you need to redo the POC. This process turns individual curiosity into a collective knowledge base. Over the years, we have hosted 250+ Tech Sessions based on POCs and actual work done in production systems.
Culture is What You Tolerate
I often say that culture is not what you say, it is what you tolerate. Most first-time leaders underestimate how costly shaping and maintaining a good culture is. It’s not what you do one time, it’s what you do every time that shapes and defines the culture.
In our lab, we focus on the habits that make a system maintainable over the long term. This includes everything from programming language hygiene to our standardised CI/CD setups. We even have a checklist for the office coffee machine.
It sounds like a small, perhaps silly detail. But it is a proxy for how we work. If an engineer doesn't have the discipline to follow a simple checklist for a physical tool that their peers rely on, they will eventually cut corners on a production deployment. We want engineers to understand that their influence comes from their craft, not their title. And craft requires a level of discipline that certifications can't teach.
Humans make mistakes. That is a hard real-world constraint. Our culture is shaped by how we view those mistakes and what we do to allow people to make mistakes with a good safety net. In our experience, reliability starts with boring checklists and guardrails, not heroic firefighting.
Engineering for Business Outcomes
I am a long-time software engineer turned Founder and CEO. I have built products from scratch that generated multi-million dollar revenue. I’ve seen how software can make money for a business and I’ve seen how it can drain it.
We work with companies facing issues with application modernisation and product engineering. What matters in these engagement is to have a team that can understand business and technology trade-offs and care about the outcomes.
By investing in the Prayogshala, we ensure our team has the muscle memory for this kind of care. By working in the Prayogshala, our engineers have already wrestled with common patterns and pitfalls in our lab. They know how to build technology solutions that can scale without scaling engineering teams linearly.
We are a technology company and we are building a culture of practitioners. We are focused on how software can make money for the business, which means focusing on the “lities” that keep a business running. Availability. Maintainability. Reliability. By the time an engineer joins a client engagement, they have already broken and fixed systems in the lab, evaluated tools like Istio, Kubecost and Keycloak and practiced explaining trade-offs to a tough audience - so clients don’t have to pay for that learning curve in production.
If you are interested in how we operate, we’ve published it all in our Playbook and Bootcamps. If you are facing a hard engineering problem and need a team that focuses on craft over cool technology, reach out to me. If you want to see how Prayogshala has shaped real client architectures, we are always happy to walk you through specific examples.
I recently spent an hour coaching a backend engineer during an interview. He spent most of his time drawing boxes on a whiteboard instead of asking questions to validate his assumptions. I asked him how he would build a set of B2B SaaS APIs for a specific use case and he jumped straight into the design. He did not ask about the pricing model. He did not ask about the expected API volume per customer. He did not ask about the timeline to ship the first version.
He started explaining a solution to a problem he had not fully defined yet.
This is a recurring theme in our industry. We have created an environment where engineers are rewarded for knowing the what but not the why. They can tell you how to set up a Kubernetes cluster but they cannot tell you if that cluster is the right tool for the business goal. In these cases, engineers optimise for “Resume-Driven-Development,” where they use tech just to add it to their resume. This results in projects that have more than twenty microservices and zero users in production.
At One2N, we wanted to fix this behaviour at the root. We realised that the only way to do this is to change how engineers learn, practice and make decisions every day. We do not just want people who know tools. We want practitioners who start from the problem, understand the constraints and then design the solution. Hence, we built Prayogshala.
Prayogshala is our internal engineering laboratory where teams build real-world POCs and turn these into reusable artifacts for client work.
Principal-Led Mentorship and the "CHOTU" Model
When our engineers aren't working on a client engagement, they work in the lab. But this isn't self-study where someone is left alone with a Udemy login. It is a guided apprenticeship led by our Principal SRE, Saurabh Hirani.
Saurabh is who we call CHOTU - our Chief Head of Talent Upskilling. The title is lighthearted but the work is rigorous. Saurabh brings fifteen years of experience building and scaling systems. He doesn't give lectures. Instead, he identifies POCs that be converted into reusable artifacts based on our work at portfolio companies of PeakXV, Accel and Lightspeed.
When an engineer picks up a POC in the Prayogshala, they are expected to own it end to end. If they are looking at OpenTelemetry, VictoriaMetrics, or ClickHouse, they are doing much more than just a simple getting started guide. They are building a functional system that has to stand up to Saurabh’s scrutiny.
He acts as the most difficult customer an engineer will ever face. He evaluates their code and also focuses on whether the code is maintainable. He will push the team to explain the trade-offs. For example, he will ask why they chose a particular data model or how their solution improves application performance. In my experience, this friction and the dialogue where an engineer has to explain “why” and “why not this” is where real growth happens.
Moving Beyond "Hello World"
The problem with most engineering training is that it stops at the Hello World stage. You follow a tutorial, the code works and you move on. But you haven't seen how your solution behaves during a network latency spike or when the data volume exceeds the memory limits.
In Prayogshala, we ask engineers to explore these “edge cases” and design their solution accordingly.
We get the engineers to take up POCs on technologies that actually matter to the business. We evaluate Istio for service mesh implementation, Kubecost for cloud cost optimisations and Warpbuild to see if we can reduce the build time for a giant monorepo. We investigate Keycloak for identity because we know how costly AWS Cognito gets in production.
The goal is to prove the solution and write about the trade-offs. Once an engineer finishes a POC, they have to deliver a Tech Session internally. This is the ultimate test of understanding. The goal is to explain your choices and answer “why” and “why not” to your peers. If you can’t do that, you’ve just followed a tutorial and you need to redo the POC. This process turns individual curiosity into a collective knowledge base. Over the years, we have hosted 250+ Tech Sessions based on POCs and actual work done in production systems.
Culture is What You Tolerate
I often say that culture is not what you say, it is what you tolerate. Most first-time leaders underestimate how costly shaping and maintaining a good culture is. It’s not what you do one time, it’s what you do every time that shapes and defines the culture.
In our lab, we focus on the habits that make a system maintainable over the long term. This includes everything from programming language hygiene to our standardised CI/CD setups. We even have a checklist for the office coffee machine.
It sounds like a small, perhaps silly detail. But it is a proxy for how we work. If an engineer doesn't have the discipline to follow a simple checklist for a physical tool that their peers rely on, they will eventually cut corners on a production deployment. We want engineers to understand that their influence comes from their craft, not their title. And craft requires a level of discipline that certifications can't teach.
Humans make mistakes. That is a hard real-world constraint. Our culture is shaped by how we view those mistakes and what we do to allow people to make mistakes with a good safety net. In our experience, reliability starts with boring checklists and guardrails, not heroic firefighting.
Engineering for Business Outcomes
I am a long-time software engineer turned Founder and CEO. I have built products from scratch that generated multi-million dollar revenue. I’ve seen how software can make money for a business and I’ve seen how it can drain it.
We work with companies facing issues with application modernisation and product engineering. What matters in these engagement is to have a team that can understand business and technology trade-offs and care about the outcomes.
By investing in the Prayogshala, we ensure our team has the muscle memory for this kind of care. By working in the Prayogshala, our engineers have already wrestled with common patterns and pitfalls in our lab. They know how to build technology solutions that can scale without scaling engineering teams linearly.
We are a technology company and we are building a culture of practitioners. We are focused on how software can make money for the business, which means focusing on the “lities” that keep a business running. Availability. Maintainability. Reliability. By the time an engineer joins a client engagement, they have already broken and fixed systems in the lab, evaluated tools like Istio, Kubecost and Keycloak and practiced explaining trade-offs to a tough audience - so clients don’t have to pay for that learning curve in production.
If you are interested in how we operate, we’ve published it all in our Playbook and Bootcamps. If you are facing a hard engineering problem and need a team that focuses on craft over cool technology, reach out to me. If you want to see how Prayogshala has shaped real client architectures, we are always happy to walk you through specific examples.
I recently spent an hour coaching a backend engineer during an interview. He spent most of his time drawing boxes on a whiteboard instead of asking questions to validate his assumptions. I asked him how he would build a set of B2B SaaS APIs for a specific use case and he jumped straight into the design. He did not ask about the pricing model. He did not ask about the expected API volume per customer. He did not ask about the timeline to ship the first version.
He started explaining a solution to a problem he had not fully defined yet.
This is a recurring theme in our industry. We have created an environment where engineers are rewarded for knowing the what but not the why. They can tell you how to set up a Kubernetes cluster but they cannot tell you if that cluster is the right tool for the business goal. In these cases, engineers optimise for “Resume-Driven-Development,” where they use tech just to add it to their resume. This results in projects that have more than twenty microservices and zero users in production.
At One2N, we wanted to fix this behaviour at the root. We realised that the only way to do this is to change how engineers learn, practice and make decisions every day. We do not just want people who know tools. We want practitioners who start from the problem, understand the constraints and then design the solution. Hence, we built Prayogshala.
Prayogshala is our internal engineering laboratory where teams build real-world POCs and turn these into reusable artifacts for client work.
Principal-Led Mentorship and the "CHOTU" Model
When our engineers aren't working on a client engagement, they work in the lab. But this isn't self-study where someone is left alone with a Udemy login. It is a guided apprenticeship led by our Principal SRE, Saurabh Hirani.
Saurabh is who we call CHOTU - our Chief Head of Talent Upskilling. The title is lighthearted but the work is rigorous. Saurabh brings fifteen years of experience building and scaling systems. He doesn't give lectures. Instead, he identifies POCs that be converted into reusable artifacts based on our work at portfolio companies of PeakXV, Accel and Lightspeed.
When an engineer picks up a POC in the Prayogshala, they are expected to own it end to end. If they are looking at OpenTelemetry, VictoriaMetrics, or ClickHouse, they are doing much more than just a simple getting started guide. They are building a functional system that has to stand up to Saurabh’s scrutiny.
He acts as the most difficult customer an engineer will ever face. He evaluates their code and also focuses on whether the code is maintainable. He will push the team to explain the trade-offs. For example, he will ask why they chose a particular data model or how their solution improves application performance. In my experience, this friction and the dialogue where an engineer has to explain “why” and “why not this” is where real growth happens.
Moving Beyond "Hello World"
The problem with most engineering training is that it stops at the Hello World stage. You follow a tutorial, the code works and you move on. But you haven't seen how your solution behaves during a network latency spike or when the data volume exceeds the memory limits.
In Prayogshala, we ask engineers to explore these “edge cases” and design their solution accordingly.
We get the engineers to take up POCs on technologies that actually matter to the business. We evaluate Istio for service mesh implementation, Kubecost for cloud cost optimisations and Warpbuild to see if we can reduce the build time for a giant monorepo. We investigate Keycloak for identity because we know how costly AWS Cognito gets in production.
The goal is to prove the solution and write about the trade-offs. Once an engineer finishes a POC, they have to deliver a Tech Session internally. This is the ultimate test of understanding. The goal is to explain your choices and answer “why” and “why not” to your peers. If you can’t do that, you’ve just followed a tutorial and you need to redo the POC. This process turns individual curiosity into a collective knowledge base. Over the years, we have hosted 250+ Tech Sessions based on POCs and actual work done in production systems.
Culture is What You Tolerate
I often say that culture is not what you say, it is what you tolerate. Most first-time leaders underestimate how costly shaping and maintaining a good culture is. It’s not what you do one time, it’s what you do every time that shapes and defines the culture.
In our lab, we focus on the habits that make a system maintainable over the long term. This includes everything from programming language hygiene to our standardised CI/CD setups. We even have a checklist for the office coffee machine.
It sounds like a small, perhaps silly detail. But it is a proxy for how we work. If an engineer doesn't have the discipline to follow a simple checklist for a physical tool that their peers rely on, they will eventually cut corners on a production deployment. We want engineers to understand that their influence comes from their craft, not their title. And craft requires a level of discipline that certifications can't teach.
Humans make mistakes. That is a hard real-world constraint. Our culture is shaped by how we view those mistakes and what we do to allow people to make mistakes with a good safety net. In our experience, reliability starts with boring checklists and guardrails, not heroic firefighting.
Engineering for Business Outcomes
I am a long-time software engineer turned Founder and CEO. I have built products from scratch that generated multi-million dollar revenue. I’ve seen how software can make money for a business and I’ve seen how it can drain it.
We work with companies facing issues with application modernisation and product engineering. What matters in these engagement is to have a team that can understand business and technology trade-offs and care about the outcomes.
By investing in the Prayogshala, we ensure our team has the muscle memory for this kind of care. By working in the Prayogshala, our engineers have already wrestled with common patterns and pitfalls in our lab. They know how to build technology solutions that can scale without scaling engineering teams linearly.
We are a technology company and we are building a culture of practitioners. We are focused on how software can make money for the business, which means focusing on the “lities” that keep a business running. Availability. Maintainability. Reliability. By the time an engineer joins a client engagement, they have already broken and fixed systems in the lab, evaluated tools like Istio, Kubecost and Keycloak and practiced explaining trade-offs to a tough audience - so clients don’t have to pay for that learning curve in production.
If you are interested in how we operate, we’ve published it all in our Playbook and Bootcamps. If you are facing a hard engineering problem and need a team that focuses on craft over cool technology, reach out to me. If you want to see how Prayogshala has shaped real client architectures, we are always happy to walk you through specific examples.
I recently spent an hour coaching a backend engineer during an interview. He spent most of his time drawing boxes on a whiteboard instead of asking questions to validate his assumptions. I asked him how he would build a set of B2B SaaS APIs for a specific use case and he jumped straight into the design. He did not ask about the pricing model. He did not ask about the expected API volume per customer. He did not ask about the timeline to ship the first version.
He started explaining a solution to a problem he had not fully defined yet.
This is a recurring theme in our industry. We have created an environment where engineers are rewarded for knowing the what but not the why. They can tell you how to set up a Kubernetes cluster but they cannot tell you if that cluster is the right tool for the business goal. In these cases, engineers optimise for “Resume-Driven-Development,” where they use tech just to add it to their resume. This results in projects that have more than twenty microservices and zero users in production.
At One2N, we wanted to fix this behaviour at the root. We realised that the only way to do this is to change how engineers learn, practice and make decisions every day. We do not just want people who know tools. We want practitioners who start from the problem, understand the constraints and then design the solution. Hence, we built Prayogshala.
Prayogshala is our internal engineering laboratory where teams build real-world POCs and turn these into reusable artifacts for client work.
Principal-Led Mentorship and the "CHOTU" Model
When our engineers aren't working on a client engagement, they work in the lab. But this isn't self-study where someone is left alone with a Udemy login. It is a guided apprenticeship led by our Principal SRE, Saurabh Hirani.
Saurabh is who we call CHOTU - our Chief Head of Talent Upskilling. The title is lighthearted but the work is rigorous. Saurabh brings fifteen years of experience building and scaling systems. He doesn't give lectures. Instead, he identifies POCs that be converted into reusable artifacts based on our work at portfolio companies of PeakXV, Accel and Lightspeed.
When an engineer picks up a POC in the Prayogshala, they are expected to own it end to end. If they are looking at OpenTelemetry, VictoriaMetrics, or ClickHouse, they are doing much more than just a simple getting started guide. They are building a functional system that has to stand up to Saurabh’s scrutiny.
He acts as the most difficult customer an engineer will ever face. He evaluates their code and also focuses on whether the code is maintainable. He will push the team to explain the trade-offs. For example, he will ask why they chose a particular data model or how their solution improves application performance. In my experience, this friction and the dialogue where an engineer has to explain “why” and “why not this” is where real growth happens.
Moving Beyond "Hello World"
The problem with most engineering training is that it stops at the Hello World stage. You follow a tutorial, the code works and you move on. But you haven't seen how your solution behaves during a network latency spike or when the data volume exceeds the memory limits.
In Prayogshala, we ask engineers to explore these “edge cases” and design their solution accordingly.
We get the engineers to take up POCs on technologies that actually matter to the business. We evaluate Istio for service mesh implementation, Kubecost for cloud cost optimisations and Warpbuild to see if we can reduce the build time for a giant monorepo. We investigate Keycloak for identity because we know how costly AWS Cognito gets in production.
The goal is to prove the solution and write about the trade-offs. Once an engineer finishes a POC, they have to deliver a Tech Session internally. This is the ultimate test of understanding. The goal is to explain your choices and answer “why” and “why not” to your peers. If you can’t do that, you’ve just followed a tutorial and you need to redo the POC. This process turns individual curiosity into a collective knowledge base. Over the years, we have hosted 250+ Tech Sessions based on POCs and actual work done in production systems.
Culture is What You Tolerate
I often say that culture is not what you say, it is what you tolerate. Most first-time leaders underestimate how costly shaping and maintaining a good culture is. It’s not what you do one time, it’s what you do every time that shapes and defines the culture.
In our lab, we focus on the habits that make a system maintainable over the long term. This includes everything from programming language hygiene to our standardised CI/CD setups. We even have a checklist for the office coffee machine.
It sounds like a small, perhaps silly detail. But it is a proxy for how we work. If an engineer doesn't have the discipline to follow a simple checklist for a physical tool that their peers rely on, they will eventually cut corners on a production deployment. We want engineers to understand that their influence comes from their craft, not their title. And craft requires a level of discipline that certifications can't teach.
Humans make mistakes. That is a hard real-world constraint. Our culture is shaped by how we view those mistakes and what we do to allow people to make mistakes with a good safety net. In our experience, reliability starts with boring checklists and guardrails, not heroic firefighting.
Engineering for Business Outcomes
I am a long-time software engineer turned Founder and CEO. I have built products from scratch that generated multi-million dollar revenue. I’ve seen how software can make money for a business and I’ve seen how it can drain it.
We work with companies facing issues with application modernisation and product engineering. What matters in these engagement is to have a team that can understand business and technology trade-offs and care about the outcomes.
By investing in the Prayogshala, we ensure our team has the muscle memory for this kind of care. By working in the Prayogshala, our engineers have already wrestled with common patterns and pitfalls in our lab. They know how to build technology solutions that can scale without scaling engineering teams linearly.
We are a technology company and we are building a culture of practitioners. We are focused on how software can make money for the business, which means focusing on the “lities” that keep a business running. Availability. Maintainability. Reliability. By the time an engineer joins a client engagement, they have already broken and fixed systems in the lab, evaluated tools like Istio, Kubecost and Keycloak and practiced explaining trade-offs to a tough audience - so clients don’t have to pay for that learning curve in production.
If you are interested in how we operate, we’ve published it all in our Playbook and Bootcamps. If you are facing a hard engineering problem and need a team that focuses on craft over cool technology, reach out to me. If you want to see how Prayogshala has shaped real client architectures, we are always happy to walk you through specific examples.
I recently spent an hour coaching a backend engineer during an interview. He spent most of his time drawing boxes on a whiteboard instead of asking questions to validate his assumptions. I asked him how he would build a set of B2B SaaS APIs for a specific use case and he jumped straight into the design. He did not ask about the pricing model. He did not ask about the expected API volume per customer. He did not ask about the timeline to ship the first version.
He started explaining a solution to a problem he had not fully defined yet.
This is a recurring theme in our industry. We have created an environment where engineers are rewarded for knowing the what but not the why. They can tell you how to set up a Kubernetes cluster but they cannot tell you if that cluster is the right tool for the business goal. In these cases, engineers optimise for “Resume-Driven-Development,” where they use tech just to add it to their resume. This results in projects that have more than twenty microservices and zero users in production.
At One2N, we wanted to fix this behaviour at the root. We realised that the only way to do this is to change how engineers learn, practice and make decisions every day. We do not just want people who know tools. We want practitioners who start from the problem, understand the constraints and then design the solution. Hence, we built Prayogshala.
Prayogshala is our internal engineering laboratory where teams build real-world POCs and turn these into reusable artifacts for client work.
Principal-Led Mentorship and the "CHOTU" Model
When our engineers aren't working on a client engagement, they work in the lab. But this isn't self-study where someone is left alone with a Udemy login. It is a guided apprenticeship led by our Principal SRE, Saurabh Hirani.
Saurabh is who we call CHOTU - our Chief Head of Talent Upskilling. The title is lighthearted but the work is rigorous. Saurabh brings fifteen years of experience building and scaling systems. He doesn't give lectures. Instead, he identifies POCs that be converted into reusable artifacts based on our work at portfolio companies of PeakXV, Accel and Lightspeed.
When an engineer picks up a POC in the Prayogshala, they are expected to own it end to end. If they are looking at OpenTelemetry, VictoriaMetrics, or ClickHouse, they are doing much more than just a simple getting started guide. They are building a functional system that has to stand up to Saurabh’s scrutiny.
He acts as the most difficult customer an engineer will ever face. He evaluates their code and also focuses on whether the code is maintainable. He will push the team to explain the trade-offs. For example, he will ask why they chose a particular data model or how their solution improves application performance. In my experience, this friction and the dialogue where an engineer has to explain “why” and “why not this” is where real growth happens.
Moving Beyond "Hello World"
The problem with most engineering training is that it stops at the Hello World stage. You follow a tutorial, the code works and you move on. But you haven't seen how your solution behaves during a network latency spike or when the data volume exceeds the memory limits.
In Prayogshala, we ask engineers to explore these “edge cases” and design their solution accordingly.
We get the engineers to take up POCs on technologies that actually matter to the business. We evaluate Istio for service mesh implementation, Kubecost for cloud cost optimisations and Warpbuild to see if we can reduce the build time for a giant monorepo. We investigate Keycloak for identity because we know how costly AWS Cognito gets in production.
The goal is to prove the solution and write about the trade-offs. Once an engineer finishes a POC, they have to deliver a Tech Session internally. This is the ultimate test of understanding. The goal is to explain your choices and answer “why” and “why not” to your peers. If you can’t do that, you’ve just followed a tutorial and you need to redo the POC. This process turns individual curiosity into a collective knowledge base. Over the years, we have hosted 250+ Tech Sessions based on POCs and actual work done in production systems.
Culture is What You Tolerate
I often say that culture is not what you say, it is what you tolerate. Most first-time leaders underestimate how costly shaping and maintaining a good culture is. It’s not what you do one time, it’s what you do every time that shapes and defines the culture.
In our lab, we focus on the habits that make a system maintainable over the long term. This includes everything from programming language hygiene to our standardised CI/CD setups. We even have a checklist for the office coffee machine.
It sounds like a small, perhaps silly detail. But it is a proxy for how we work. If an engineer doesn't have the discipline to follow a simple checklist for a physical tool that their peers rely on, they will eventually cut corners on a production deployment. We want engineers to understand that their influence comes from their craft, not their title. And craft requires a level of discipline that certifications can't teach.
Humans make mistakes. That is a hard real-world constraint. Our culture is shaped by how we view those mistakes and what we do to allow people to make mistakes with a good safety net. In our experience, reliability starts with boring checklists and guardrails, not heroic firefighting.
Engineering for Business Outcomes
I am a long-time software engineer turned Founder and CEO. I have built products from scratch that generated multi-million dollar revenue. I’ve seen how software can make money for a business and I’ve seen how it can drain it.
We work with companies facing issues with application modernisation and product engineering. What matters in these engagement is to have a team that can understand business and technology trade-offs and care about the outcomes.
By investing in the Prayogshala, we ensure our team has the muscle memory for this kind of care. By working in the Prayogshala, our engineers have already wrestled with common patterns and pitfalls in our lab. They know how to build technology solutions that can scale without scaling engineering teams linearly.
We are a technology company and we are building a culture of practitioners. We are focused on how software can make money for the business, which means focusing on the “lities” that keep a business running. Availability. Maintainability. Reliability. By the time an engineer joins a client engagement, they have already broken and fixed systems in the lab, evaluated tools like Istio, Kubecost and Keycloak and practiced explaining trade-offs to a tough audience - so clients don’t have to pay for that learning curve in production.
If you are interested in how we operate, we’ve published it all in our Playbook and Bootcamps. If you are facing a hard engineering problem and need a team that focuses on craft over cool technology, reach out to me. If you want to see how Prayogshala has shaped real client architectures, we are always happy to walk you through specific examples.
