This article presents a new approach to engineering leadership, based on experience gained in a high-growth environment from 2014 to 2020 and the changing pace of work due to Imprint's rapid growth and introduction of AI tools in 2025. The author explains why these rules are important and how to apply them through specific projects carried out over the past year, highlighting key strategies for organizational success in a technology environment that is changing more rapidly than ever before.

1. Revised engineering leadership rules ✨

1.1. Migration can be led by individuals 🏃‍♀️

In the past, migrations that were complex and involved large changes were considered something that required multiple teams to collaborate for a long time. But now one or two individuals can lead more than 95% of the migration, and it can be completed in much less time. As the initial cost of a migration falls, the quality of the outcome becomes more important. Even a small problem can ruin your colleagues' understanding of the software. We live in an era where the influence individuals have on a company is greater than ever!

1.2. Your development environment (Harness) determines the cost of your working code 🛠️

Many companies these days say 'everyone should write code', but in reality, writing code that works well and avoiding unexpected problems is still difficult. The difficulty of writing code largely depends on the development harness, including testing, CI/CD, verification environments, and change preview capabilities. Although the marketing team will not directly reduce server resources, it does mean that an environment where participation is possible within safe boundaries is important. Don't forget that improving your development environment is as important today as it was two years ago!

1.3. Most processes can be optimized to be agent-centric 🤖

Most processes can be handled through automated agents at an early stage. With the right development environment, control system, domain knowledge, and good designer judgment, the early stages of most processes in modern technology companies can be fully automated. For example, a well-designed development environment can provide much faster and more effective code reviews than human code reviews. Of course, agents may miss some things, but so do people, and most areas can be changed relatively safely. If you effectively identify and deal with specific high-risk areas, you can proceed much faster and without risk. 😮

"Human planning together is still important, but it must operate at a higher level."

1.4. Solid teams with high ownership have become more important 🤝

One of the biggest lessons I learned from my previous time at Uber is that permanent, strong teams achieve amazing results. These teams create magical results by building domain knowledge, building camaraderie, and strengthening a sense of ownership of a specific area. Even in the age of AI, certain tasks can be done much more cheaply, but you still have to do the 'right thing'. This has become slightly easier, but not fundamentally easier, and structural improvements will help solve this problem.

There is often a perception that in AI-centric companies, a small number of genius engineers will produce perfect results one by one and do it so well that maintenance is not necessary, but I don't see it that way. Individuals with great judgment can do amazing things for an entire company, but they will ultimately be limited by a lack of domain knowledge. That's why robust teams will remain a fundamental building block in the AI ​​era. 💪

1.5. Fast, correct and sustainable decision-making is a prerequisite for using AI 🎯

Replacing legal review with automation is only possible if legal teams embrace the change. This is only possible when automation is designed carefully and teams are willing to collaborate. Implementing a new feature is only worthwhile if you can decide to release it.

For companies to benefit from this increased speed of execution, they must be able to make fast, good, and sustainable decisions. In my opinion, this is the main reason why the average CTO role has become much more technical and less bureaucratic than it was a year ago. When there are disagreements between teams, you're often the only one who can make binding decisions, and in the new environment, you're constantly making decisions to keep up the pace. 🗣️

2. Real-life application cases 💡

I will share specific examples of how the above rules were applied through projects carried out at Imprint over the past year.

2.1. Migration project examples 🔄

• Improved deployment process: A year ago we were deploying manually about 6 times a week, now we are deploying 200-400 times a week! 😲 Engineering staff has doubled, but the number of deployments has increased 20 to 30 times. This is thanks to two members of our infrastructure team leading a two-month migration that completely changed our deployment approach.
• Adoption of AI coding tools: At the beginning of January, only about 25% of team members were using Claude Code or Cursor, but by the end of February, 100% were using it. It was a natural change that occurred by providing good tools and relieving inconveniences without instructions from above. Now almost all PRs are drafted by AI.
• Unification of settings management: The various setting mechanisms have been unified into two. In the past, this would have been a project that would have taken several people and several years, but with one or two engineers leading the project, it was completed in one quarter, and we even created new internal tools to help both engineer and non-engineer teams manage value.
• Front-end monorepo conversion: The front-end application architecture, which was distributed across multiple repositories, was consolidated into a monorepo in one month. One front-end engineer took the lead for 95%. You now have a shared development environment, reduce library maintenance costs, and completely eliminate the friction of using npm.
• Static typing of front-end code: We went from largely untyped front-end code to completely static typing in a matter of weeks. This too was accomplished by one engineer.
• Package Manager Replacement: Switched from npm to pnpm to strengthen security defaults and speed up deployments. It was accomplished by one engineer investing several hours a day over several days.

2.2. Experiences that helped me realize that the development environment determines the cost of working code 💡

• The evils of poor PR and design documents: If we handed over half-baked design documents or PRs to engineers on other teams, no progress was made. Although these things are inexpensive to make, they can actually be harmful. Not only does it require modification, but it also pollutes the context of the Large Language Model (LLM), which is worse than starting from scratch.
• Effectiveness of Admin Code Contribution: We've seen tremendous success when admins are directly involved in software development, checking dashboards after changes are made, and troubleshooting issues as they arise. However, in cases where this process was not followed, little positive impact was found.

2.3. Agent-centric process optimization cases 🤖

• Automatic classification of customer support issues: Agents automatically classify all issues that come in from the customer operations team. These agents use team information, open tickets, and data warehouse access to measure the impact of an issue. This is a complex and skilled task, but it is now done faster and more efficiently through agents. Of course, there is still a human verification process in case of exceptional cases. Importantly, this was done by automating some steps without changing the human workflow.
• Automated code review drafting: The same development environment that implements code changes drafts code reviews. This allows people to focus on more valuable feedback.
• Adopt company-wide AI tools: Last quarter, we rolled out Claude Code and Cowork to all employees, and saw them automate many tasks. In particular, our fraud prevention team has been very active in automating the initial investigation of potential attacks, replacing manual work with automated, data-driven drafting.
• Move to Linear: Improved workflow by adopting Linear instead of Jira. With a more robust Master Control Program (MCP) and improved Slack integration, every employee has a better infrastructure to build agent-centric workflows. We are now testing an internal system that pulls issues from Linear and automatically resolves them, and that is our next goal.

2.4. Examples that demonstrate the importance of a strong team 🤝

• Building a Dedicated Team: When I joined, we had a great team of people rapidly rotating through different areas for each project. Of course, work progressed, but it was difficult to respond immediately when problems occurred. We now have at least a small dedicated team in every important area of ​​the company, and these teams continue to invest and take advantage of all the new technologies that AI has to offer. Without these teams, these opportunities would not have been possible.
• SierraAI development and improvement: We launched SierraAI, and since then the team has iterated tirelessly to make it truly great. This would not have been possible without a dedicated and focused team.

2.5. The need for fast, correct and sustainable decision making 🎯

• Changing the configuration method: Changing the configuration method was a controversial decision and required multiple explanations. This decision would have been very difficult to make from the bottom up, as it affected each team differently. Because the benefits of your decisions play out at the whole system level.
• CI/CD Pipeline Retool: Retooling the CI/CD pipeline has also been controversial. This is because it changed many people's perception of how deployments and releases should be done (e.g. we had to explicitly separate deployments from releases via feature flags). This too would have been slow and difficult to decide from the bottom up.
• Web Monorepo Consolidation: Consolidating into a web monorepo was also a controversial decision with many different opinions, but the integrated decision-making brought great benefits.
• Introduction of SierraAI: The introduction of SierraAI went through difficult discussions, not only comparing it with competing products, but also considering not introducing it at all. A decision from management was needed to conclude this cross-functional discussion.

These are just representative examples; in reality, much more has been done. Every month this year, the scope of 'what's possible' continued to expand, but the things holding us back (organizational misalignment, lack of clarity, poor technical architecture) didn't change much. What an exciting time to be working in technology! 🎢

Conclusion 🌟

Engineering leadership in the AI ​​era depends on individual capabilities, an optimized development environment, agent-centric process automation, a team with strong domain knowledge, and rapid and accurate decision-making. In this wave of change, we will need to constantly rethink and innovate our organizational structure and work methods. 🚀