It was created by our senior technologists who’ve seen how strategic team management raises delivery performance by 20-40%.

TL;DR

• Some managers block AI-driven teams with rigid rules & instructions,

• Managers who complement AI help them see what’s worth building,

• They give the team a lot of autonomy, stepping in only when needed,

• Such a mindset is necessary to maintain a high AI development speed.

Contents

1. When management enables engineers

2. Anti-AI management style

3. Staying useful

Hey!

Andrzej here.

IT managers always try to figure out how to get their developers to be more efficient with AI tools.

This is also a major topic here at Effective Delivery.

But today, I want you to think about yourself.

What if you, as a manager, are the reason why productivity didn’t improve so much with AI?

When management enables engineers

AI has made coding dramatically faster, with our AI framework, copilot-collections, allowing engineers to build some end-to-end features in 30 minutes.

But it’s not just about coding. AI also speeds up work across multiple other aspects of a developer’s day. With it, developers can:

• generate their own tasks from a brief,

• quickly summarize information,

• learn about new topics, communicate, get updates, and more.

This can result in an autonomous developer who uses AI assistance to gather a wealth of context and generate new tasks fast, completing them even faster.

They can do it all on their own, without any oversight.

That kind of autonomy can absolutely work, but only if you, as a manager, allow it.

Anti-AI management style

Some managers still haven’t adjusted their managerial style to AI, resulting in all that potential being wasted by one of the 3 traps.

The bottleneck trap

Some managers simply can’t let a decision leave their hands.

They approve the tiniest tasks, library or plugin choices, sign off on every scope change, and hold every option open until they say so.

Teams that could run at AI pace sit idle instead.

They wait for a decision they could have made themselves.

On a recent project, developers finished their tasks in 3 days.

Then they waited another 3 days for each approval step.

Half of the AI speed advantage disappeared in that waiting room.

The ownership trap

When managers don’t let anyone make decisions, the consequences go beyond just wasting time.

They shape a team composed of people who are too scared to make any decisions on their own and too detached from the product to care about it.

“I’m just doing my job” is what goes through their head.

Will such developers make the effort to understand the user they are creating for?

And when the decision-making is limited by the creativity of a single person, could it ever be optimal?

The activity trap

Some managers love tracking metrics like velocity or tasks shipped because they make it easy to show that they are doing a lot.

It’s even more true in the age of AI, where a skilled engineer can produce so much code with the help of agents.

But when a manager is stuck on velocity, smart developers who lack a sense of ownership will close their whole sprint in 3 days and pretend to work for the rest of it.

If velocity is what gets rewarded, velocity is what’s delivered.

Staying useful

Because of AI, the cost of writing code has dropped through the floor.

But the cost of building the wrong feature or shipping a bad product is as high as ever.

If you want to be useful as a manager today, don’t focus on details and volume of work.

1. Communicate the purpose

A manager must answer 3 questions about the project without hesitation.

• Who is the user?

• What problem are we solving for them?

• How do we know the problem exists?

If a manager can create a high-level definition of done for a feature or an app, they can let AI and developers determine how to get there.

The developer will be responsible for defining the done for operational tasks that bring your vision to life.

2. Help decide what NOT to do

Instead of giving your teams rigid instructions, help them narrow down their choice.

A manager needs to say “we are not building this,” even against the client’s wishes.

The willingness to break a roadmap when it no longer serves the goal is essential now that writing new code is this fast.

3. Measure outcomes, not activities

As my friend Adam wrote, there are only 4 metrics that affect quality and timely delivery:

• Lead time

• Cycle time

• Deployment frequency

• Product bugs

4. Give your team more space

I design the team so the work can run for a week without me.

It starts with naming what the team decides without me and keeping my hands off inside those lines.

Think of how an insurance agent gets his pricing range.

He can close a deal anywhere between 500 and 1000, but to go below that, he has to pick up the phone.

The range is the team’s autonomy, and the phone call is where I come in.

Guaranteed results →

5. Focus on unblocking

Rather than blocking your team’s creativity, do the opposite.

Every month, I review the team’s processes and cut anything that no longer earns its keep.

A simpler system lets the team react to project shifts and frees AI to carry more of the load.

But I also encourage managers to step in decisively when they actually see a problem.

On one project, one of our solution architects saw a long custom build estimate.

He found a ready library that covered most of the scope.

The team dropped the custom code path and delivered on time.

Next time

Aleksander Patschek will tell you why the latest technology isn’t always the right choice.

He will help you choose between the tried-and-tested and the new and innovative, depending on what your project really needs.

Happy weekend!

🟣 The latest AI-efficiency tactic

Published with a smirk by The Software House

Twarda 18, Warsaw, Poland

tsh.io →

It was created by our senior technologists who’ve seen how strategic team management raises delivery performance by 20-40%.

TL;DR

• AI productivity gains rarely exceed 40%,

• Pro users go beyond the cap by running a team of AI agents,

• AI superusers coordinate many such teams at once,

• My own developers achieve 1000% productivity this way.

Contents

1. The AI efficiency ceiling

2. 3 levels of AI agent use

3. Implementing multi-task agents

Hey! Adam here.

Your IT team may implement best practices in AI development and still achieve only a modest efficiency boost.

Developers who use a single AI agent to handle one task at a time quickly reach a ceiling.

My top engineers use many agents in parallel, raising output by 1000%.

The AI efficiency ceiling

When I talk about an AI productivity boost, I mean how much faster one developer can deliver a feature from start to finish.

When you introduce AI tools, you may see varying gains:

• Some report a boost of only 5%,

• Some report 20-30%,

• Our AI framework gives a baseline of 40% to all who use it properly,

• Some pros improve by 70-100%.

This is where even those heavy-hitters find their limit.

But there’s a world beyond this single-threaded AI use.

3 levels of using AI agents

At TSH, we’ve long had a policy of giving more freedom with AI tools to those who deliver great results.

Over time, 3 advanced levels of AI usage emerged:

Level 1

A few agents for one task without automation

A developer uses a few agents, each built for a different task, such as writing tests or generating components.

The developer runs the agents in a specific order.

Level 2

A few agents for one automated task

The developer adds an orchestrating agent on top of the task-specific agents.

The developer gives commands to the orchestrator.

The new agent decides which agents to run and in what sequence.

Unblock Delivery in 2-4 Weeks

My engineers at TSH help organizations fix delivery blockers in 2 sprints max.

Guaranteed results

Level 3

Multiple agent groups with many tasks automated

The developer runs the coordinating agent and the task-specific agents across multiple tasks at once.

Those separate agent groups work on multiple tasks in parallel.

Level 3 is where the superpower is.

An engineer who can do it becomes a master puppeteer, managing layers of AI agents that do all the work while the human verifies the output.

One of our engineers worked on 3 features at once using agent groups.

This approach multiplied his delivery beyond what any single-threaded user could achieve.

He delivered several times more story points than his peers, who already ranked in the top 30 AI users at our company.

Implementing multi-task agents

As great as it all sounds on paper, keep in mind that there are reasons why multi-task agents aren’t a one-size-fits-all solution.

Account for technical limitations

The developer can’t run many agents in the same codebase, each doing different tasks at once, because that would result in conflicts.

They need to create separate copies of the app state to form a worktree.

Each agent group works on a different branch of the worktree.

Frontend tasks adapt better to this because the backend ones require the developer to duplicate the database for each branch.

Pick the right adopters

Not every developer can become an AI superuser.

Some prefer hands-on coding, while others thrive as specialists and struggle with context switching.

The best candidates have T-shaped experience, combining deep coding expertise with broad knowledge in areas like architecture or DevOps.

Lead developers, solutions architects, IT managers, and staff engineers fit this pattern.

Lead the change

To get started, follow these 3 steps.

1. Locate the best candidates for the multi-agent approach

It requires a developer with the right skills and mindset.

Superusers may also emerge when you give your best developers more freedom.

2. Avoid bottlenecks

Assign less experienced developers to your superusers so that they can learn from them.

That way, your development won’t come to a halt when the superuser is unavailable.

3. Verify the output

Regardless of how fast your AI developer is, the same quality controls should apply.

In our projects, AI may generate 100% of the code, but humans always verify its quality.

Next time

Andrzej Wysoczański will explain the divide between IT managers who focus on business growth and those who create development roadblocks through micro-management.

One side risks getting replaced by AI!

Most subscribers haven’t seen this

Published with a smirk by The Software House

Twarda 18, Warsaw, Poland

tsh.io →

It was created by our senior technologists who’ve seen how strategic team management raises delivery performance by 20-40%.

TL;DR

• With AI, top developers can produce features in 30 minutes,

• That’s why IT Managers believe any engineer can reach similar performance,

• The truth is that AI tools empower great engineers the most,

• Problem-solving, high-level overview, and research are key AI skills.

Contents

1. How senior devs use AI

2. Why bad developers can’t master AI

3. Empowering AI adoption

Hello!

I’m Marek, the COO and former CTO of The Software House.

My good friend Adam, our CTO, has recently shared a story here about our first 100% AI-driven project.

It shows how an AI framework like ours can speed up the life cycle multiple times.

It’s a great read, but it may have left some IT managers with the impression that with AI, you can have a pro team with little to no engineering experience.

I watched this and other AI-driven projects enough to know that it’s not true.

How senior devs use AI

Over the past several months, we have been developing our own AI framework, copilot-collections.

The framework reflects our style in 3 ways:

• it’s fed the same knowledge and standards that our developers follow,

• the 4-stage workflow it uses is similar to what we do even without AI,

• its 12 agents are often digital versions of our top engineers.

The quality is excellent too.

We’ve designed the framework to produce code as technically sound as what we would write manually.

In the last project, we set up SonarQube, the review tool we use, to reject any AI code that didn’t achieve a score of 4.7/5.

But just because our engineers can doesn’t mean everyone can too.

Why bad developers can’t master AI

For all its usefulness, there are reasons no AI framework will produce great results without skilled, dedicated humans behind it, especially in the long term.

AI doesn’t know what your problem is

When your developer uses copilot-collection’s 4-step development process to make a feature or an app, things may go well at first.

The smooth start lasts until they encounter a problem that requires more than a log or code analysis.

When the problem is not a bug, but a misalignment of intent or a complex architectural failure, AI struggles due to a lack of proper context.

But when a detailed diagnosis is provided, AI can implement it effectively.

One developer couldn’t understand why an AI-coded feature loaded slowly.

Another developer suspected the problem might be in ORM requests and prompted the AI to optimize them specifically.

The performance immediately improved.

AI needs just a little help… but very often

When I watched some of our top engineers work with copilot-collections, I even caught myself thinking the app was almost writing itself.

In fact, that’s what they were telling me as well!

But when I pressed them, I found that they were performing tons of microoperations at every step, which made the outcome possible.

The microoperations include:

• Manually changing the generated tasks’ descriptions,

• Troubleshooting micro issues,

• Quick reviews of the AI output,

• Providing the agents with proper access.

The diversity of these microoperations means that the best AI developers often have broad knowledge rather than deep specialist expertise in one field.

One of our top AI users is a DevOps expert and a manager who hasn’t coded in 10 years.

AI needs your constant attention

When dealing with AI, developers must stay on guard, not just during development but also outside of it.

The AI field is still nascent and evolving fast.

If your developers don’t have time to research and introduce innovations, your tried-and-tested AI approach may quickly become obsolete.

In the past, there were no standardized approaches to architecting LLM-based solutions.

We were reduced to simply writing prompts or creating our own systems, which took a lot of time.

When concepts such as Retrival-Augmented Generation (RAG) and agentic systems emerged, we could develop complex LLM features more quickly.

Empowering AI adoption

With so many considerations, you may now think that mastering AI tools is too hard.

But your engineers get there as long as you remember two rules.

Build a culture of tight verification

Your AI developers must use their brains when prompting AI and verify its inputs at every step.

Have them pay special attention to the high-level outcomes that AI cannot verify on its own.

Give the champions more freedom

Developers who verify their work and achieve excellent productivity by using multiple agents deserve more freedom with AI tools.

It will allow them to reach new heights in productivity.

Our copilot-collection provides that freedom by making it easy to customize workflows and modify outputs by hand.

We did it to empower our engineers.

Developers with limited experience are better off with a stricter framework that doesn’t allow for deviations from the workflow, minimizing failure risk.

Upskill engineers in 30 days →

Next time

Adam will show you how some incredible AI champions achieve 300% or even 1000% (for real!) of the output of regular AI users.

Can you find a champion like this within your own team?

If you want to find out and you haven’t subscribed yet, be sure to do it now!

How our CTO cheats at work

Published with a smirk by The Software House

Twarda 18, Warsaw, Poland

tsh.io →

It was created by our senior technologists who’ve seen how strategic team management raises delivery performance by 20-40%.

TL;DR

• I used up to 10 weekly to answer questions about our projects,

• AI could do it for me as long as it had access to the right knowledge,

• We used AI to collect project knowledge and answer questions about it,

• My AI butler saves me 1-2 hours a day and others report time saved as well.

Contents

1. Why I built my AI butler

2. The AI’s structure & workflows

3. Plans for V2

Hey! Adam here.

As a CTO, I get a ton of project questions from my teammates.

It’s my job to help them.

But freeing myself from the easiest 80% of questions thanks to my new AI chatbot allowed me to focus on the challenging ones.

Why I built my AI butler

Project questions come from 3 types of people.

Sales

They look for projects that match a new client’s domain, technology stack, or region so they can build a proposal

Marketing

They search for project details for use in content such as case studies, landing pages, or a dedicated offering for a potential client

Engineering managers

They may want to find out which project used a given framework or approach, so that they can ask the person who implemented it for advice

But I am just one person.

I don’t always have the time for every request.

I thought I could make mine and their lives easier with AI.

At this point, I didn’t know whether the idea would succeed, so I wanted a quick, easy MVP to validate it.

My plan had 3 steps.

1. Give EMs a way to assemble key knowledge from any project quickly,

2. Set up an AI chat that answers questions based on that knowledge,

3. Give everyone (who needs it) access to it via a custom chat.

The AI’s structure & workflows

Structure

My AI butler is based on 2 key elements.

1. copilot-collections

This is TSH’s own AI development framework built on top of GitHub Copilot.

It includes 1 agent relevant to the AI assistant — the knowledge-building agent.

2. Custom GPT

It’s a custom version of ChatGPT.

The tool is configured with a system prompt that defines its role as a project-matching agent.

It currently uses the GPT‑5.4 Thinking model.

Workflows

The system has 2 distinct workflows: knowledge building and knowledge querying.

1. Knowledge building

The knowledge-building workflow runs in 3 steps.

1. The EM starts copilot-collections to analyze project knowledge,

2. An agent generates a standardized markdown file,

3. The custom GPT chat gets the file and learns about the project.

It’s worth mentioning that we classify each project made for the same client separately, as each may use different technologies, libraries, concepts, and approaches.

The IT team built 3 separate applications for one specific client.

The AI project assistant considers each as an independent project with its own separate space in the markdown file.

2. Knowledge querying

For users other than EMs, this is the only important workflow.

1. A user with access to the AI project assistant enters a query in it,

2. The assistant goes through all the files it has, which are classified by region (each file having many different projects from the same region),

3. The assistant returns the answer, which may be a list of fintech projects or a list of projects that involve developing an export-to-PDF functionality.

A salesperson had to identify all TSH projects with fintech experience.

The chat returned a full list without requiring any search across company systems.

Plans for V2

Using my AI chat assistant saves me 1 to 2 hours every working day or 20-40 hours a month.

It also helps people who would not have reached out to me in the first place, so the total time saved across the organization is even greater.

The current version has 3 limitations worth knowing before you build your own.

• You can’t upload more than 20 files at once, which forced us to group project knowledge by region, potentially reducing precision,

• There is no shared search history, so 2 salespeople can run identical queries without either knowing,

• We need to pay a $20 per-user license fee for each ChatGPT account, regardless of how often each person uses it.

Given how successful the project is, I already have a more advanced version in the works.

It will likely be a custom application built on OpenAI’s visual Agent Builder.

It will connect additional data sources such as Confluence, track usage per user, and use token-based pricing rather than a per-user monthly subscription.

Don’t jump straight to the complex version, though.

Each organization is different, and there’s no telling if an app exactly like this is good for you.

My recommendation is to build the simple version first, test it for a few weeks, and commit to a more advanced build only if the results justify it, as in my case.

How does this work?

Next time

Effective Delivery #22 will cover my observations on why some engineers use AI coding tools 200% more efficiently in a real project than others.

Perhaps it’s not just a natural talent, and there’s a way to learn it?

Stay tuned and find out.

Thanks for reading today ✌️

🫵🏽 I know you haven’t read this yet

Published with a smirk by The Software House

Twarda 18, Warsaw, Poland

tsh.io →

It was created by our senior technologists who’ve seen how strategic team management raises delivery performance by 20-40%.

TL;DR

• We used our AI framework to develop the entire code in a project for the first time,

• Development speed was great, but backlog and code review produced bottlenecks,

• It turns out you can’t fully automate coding without speeding up the rest of the SDLC,

• In an AI SDLC like this, all humans, not just engineers, focus on directing and verifying.

Contents

1. Our first 100% AI-driven project

2. Can you develop too quickly?

3. Speeding up the whole SDLC

4. My view on AI-driven development now

Heyo! I’m back!

My company has long stopped thinking about AI as just a coding assistant.

We’ve understood that the real productivity gain comes when you let AI drive the work and have engineers focus on directing and verifying AI.

This is a philosophy behind our own AI-driven development framework, copilot-collections (link opens in a new tab).

We’ve already tested it in +50 commercial projects.

However, we only recently used it to cover 100% of the development in a single project.

This project, though ultimately successful, revealed delivery bottlenecks that informed the further development of our AI framework.

Our first 100% AI-driven project

The client chose a no-code approach and used Lovable to build a web app prototype for managing products and conducting research in its industry.

The goal was to turn it into maintainable software with a view to offering it as a SaaS.

Given the project’s somewhat limited budget, we proposed covering 100% of development with our framework for structured AI development.

It would lower the cost and provide an opportunity for an all-AI approach.

3 factors made this project a good fit:

• It was a monorepo, giving the AI agent all the software context in one place,

• It was mostly greenfield (after the Lovable cleanup), allowing AI to skip legacy burden,

• The size was right, complex enough to be a test, not too large for a failure to sting,

We estimated it would take 3 developers several months to do it the traditional way.

We planned to deliver it with 1 developer at the same time, with no loss of quality.

The development would be supported by a BA and a designer, for a full team of 3 people, not counting a developer on the code review duty.

Can you develop too quickly?

The project used copilot-collections’ standard 4-phase workflow of Research, Plan, Implement, and Review.

The developer completed end-to-end features in 30 to 40 minutes for standard tasks and around 3 hours for complex ones.

Several pull requests landed every day from a single developer.

As a result, the team ran into 3 bottlenecks in quick succession:

1. A dry backlog

The developer completed tasks faster than the BA could generate new ones.

What’s more, AI-driven development produced code far closer to the original acceptance criteria, leading QA to find fewer bugs and empty the backlog ever faster.

2. Slow code review

While QA was fast, pull requests covering complete features required far more review time than those for partial ones.

3. Frequent merge conflicts

Before the client-side developer adopted copilot-collections, they used a different set of AI tools and processes, which led to branch conflicts during PR merges.

It was like a factory where the production line sped up, but the ability to supply the raw materials and move the finished product didn’t.

Soon, development was idle, waiting for new tasks, while the review work piled up.

Speeding up the whole SDLC

The idea of speeding up backlog generation and code review wasn’t new to us.

After all, copilot-collections always had a review agent and a separate frontend reviewer to verify UI implementations against Figma designs.

But when we chose to use AI for 100% of the coding in a somewhat large project, it turned out not to be enough.

We needed to speed up the extreme ends of the SDLC more.

Backlog generation

First, we added a new Business Analyst agent to copilot-collections to generate a full backlog of tasks from workshop notes and stakeholder materials.

This has resulted in 3 major changes to the backlog generation process:

• The agent, rather than a human, now produces task descriptions with acceptance criteria and flags unclear or missing requirements,

• The human BA’s role shifted from writing tasks to verifying AI output and facilitating stakeholder conversations,

• Generating a backlog of 600 tasks with this agent took around 3 hours, compared to 2 weeks or more by hand,

Quality & review

Our framework’s Implement phase ends with a Code Reviewer agent check before the developer opens a pull request.

The IT team introduced new layers of automated quality control on top of the standard Code Reviewer agent that fires following the Implement phase:

• SonarQube now runs alongside every check with a strict configuration designed to detect bugs, vulnerabilities, and code smells,

• A dedicated AI job now performs a weekly Code Quality Review.
  
  We’ve set it up to look for dead code or duplicate logic of the kind that SonarQube often misses,

• An agent automatically fixes everything the weekly job finds,

The weekly code quality job flagged multiple dead code instances that SonarQube had not caught.

An agent resolved all issues in a single session, keeping the codebase clean without adding manual work to developers’ schedules.

The merge phase is the least automated step in the current process.

When a developer opens a pull request, a second developer reviews the code, and a QA specialist tests that branch before it is merged.

Luckily, following the strict, mostly automated review process, there are usually few issues left for manual work.

After these changes to the SDLC, sprint velocity stabilized.

How my view on AI-driven development shifted

AI development is still a young field, and each experience alters my perspective on it.

This time, I’ve learned enough to call it a major shift in my understanding of AI-driven development.

True AI-driven development is coming

I’ve long wanted an AI to be the primary coder rather than a coding assistant, with a human acting as the director and ultimate verifier.

But it turned out that true AI-driven development was not sustainable when most of the SDLC was still manual.

BA’s role is evolving

A human BA should use their soft and analytical skills to communicate with stakeholders and produce quality primary materials that inform AI agents.

In this new role, they can be a creative force rather than an inputter of manual tasks.

Vibe-coding has its place

Apps built with tools like Lovable are justly criticized for subpar code, but they are great for quickly producing PoCs.

I can see full-on AI-driven development like ours becoming the natural next step in transforming those vibe-coded apps into production-ready software.

How does this work?

Next time

I built an AI version of myself called 🇵🇱 Polak AI, which my teammates consultwhen I don’t have time to reply (which happens often!).

Full breakdown in Effective Delivery #21

Thanks for reading today 🫡

We’re legally obligated to show you this

Published with a smirk by The Software House

Twarda 18, Warsaw, Poland

tsh.io →

It was created by our senior technologists who’ve seen how strategic team management raises delivery performance by 20-40%.

TL;DR

• 95% of AI PoCs fail because executives are too ambitious,

• A PoC must reflect the company’s AI readiness to succeed,

• Companies that lack quality data should target PoCs based on incoming data,

• Only a high AI readiness lets companies build multi-agent AI PoCs.

Contents

1. The AI ambition trap

2. A beginner’s AI PoC

3. An intermediate AI PoC

4. An advanced AI PoC

Hey there, it’s Aleksander again.

As a Solution Architect at TSH, I’ve helped 11 clients launch their AI PoCs through workshops and consulting.

95% of AI pilots fail to turn into products, according to a 2025 MIT report.

My experience tells me that it is because companies often attempt PoCs that are simply too hard for their organizations to handle.

Today, I’ll show you how to prevent that with a set of AI PoC guidelines tailored to three AI readiness levels.

The AI ambition trap

The standard AI proof-of-concept process follows 4 steps.

1. Gather information,

2. Build the PoC,

3. Report the findings,

4. Make the decision,

This process is correct, but it doesn’t protect you from attempting a PoC that is too hard for your company.

It won’t stop you from trying to enhance a process with AI when you don’t have the right historical data.

It won’t flag a PoC that will take too long to validate.

This standardized process leaves room for excessive ambition to become the biggest obstacle for a PoC.

The goal is to match that ambition to what your organization can afford to carry to development.

A beginner’s AI PoC

Who is this for

These guidelines are for organizations that:

• do not have structured AI-ready data,

• have not built AI-enhanced features before,

• and do not have machine learning experts on board.

Your PoC guidelines

Focus on generating the right ideas first

If you struggle with data, ideas that rely on it are off the table.

Create AI PoC ideas that focus on handling incoming rather than historical data, such as document processing.

Brainstorm with the internal team and ask end users or employees where they lose time.

Consult legal before building anything with AI, because the legal department can block your idea for many reasons.

An IT team can spend months building a feature only to discover that it is a legal dead end.

The reasons can include violations of contracts, data regulations, or industry-specific policies.

Find an experienced partner

A technological partner who has deployed AI before can flag other risks the IT team might not consider, such as data handling, error handling, and compliance.

A partnership like this can take the form of workshops to develop a viable AI PoC.

If the IT team lacks AI expertise, this kind of partnership is also a way to build some, regardless of which direction the PoC goes.

Don’t insist on AI

Perhaps AI isn’t for you now. If there is no process to speed things up and no strong data to support more complex actions, try a different direction.

One client insisted on adding AI to a feature even after we showed that a traditional solution would be cheaper and faster.

The client wanted AI because it was trendy, not because it solved a problem.

Forcing AI into a process that does not require it can make the workflow worse, not better.

An intermediate AI PoC

Who is this for

Let’s now focus on organizations that:

• attempted 1 or 2 AI PoCs before,

• have some AI expertise on board,

• maintain at least some structured process data.

Your PoC guidelines

Pick a non-critical, boring process

You may feel confident with your AI expertise.

Still, don’t be more ambitious than you need to be.

Try automating time-consuming tasks, such as document processing, data extraction, or content summarization.

Choosing a non-critical process is important because the IT team wants to improve work without risking a break in a larger system.

Stay within 2 weeks

If the PoC takes longer than 2 weeks, it’s a sign that you’re going too deep.

Those 2 weeks should answer 2 questions:

• is this idea possible to build?

• should the IT team build it?'

Estimate production costs during the PoC

At this level, you should build AI PoCs with a high likelihood of going to production, not just for education.

Consider this right from the beginning.

Testing costs little, but running the same feature in production can cost much more.

If the estimated cost is too high, reduce the scope.

Work asynchronously

If you have an ambitious idea that you really don’t want to abandon, there may be a way.

Start with the most basic PoC possible.

While it’s in development, generate the data you’ll need to broaden the PoC’s scope.

A client lacked the structured data for a complex PoC.

They started smaller while the organization collected and organized data in parallel.

In 2 months, that data became historical and usable for the next iteration.

An advanced AI PoC

Who is this for

This is dedicated to organizations with:

• clean, up-to-date data,

• a strong technical organization,

• at least some actual AI experience.

Quality data is the true differentiator.

As long as you have it, you may qualify for this bracket, even if your IT team has not done much AI product development yet.

Your PoC guidelines

Follow the same steps, but extend the scope

At this point, you may feel that you have the means to skip the PoC process and go straight to development.

Hear me out.

The more ambitious your idea is, the more it will cost you if it fails.

A complex chatbot, when implemented incorrectly, can cost you tons of money in tokens wasted on user queries that should have been blocked.

Having more money does not mean the IT team can skip the validation.

However, what you can do is:

• extend the PoC to 3-4 weeks,

• use internal data to train models and fine-tune the solution,

• go for complex projects, like chatbots,

• try a multi-agent solution.

The main difference between mid-level and advanced IT teams is how many things they can automate with AI using their data.

Use milestones

If you want to validate a complex project, but still have something to release early, reverse the typical process of extending a basic idea.

Think of the whole complex solution first.

Then, figure out if you can validate just a part of it and make that your first milestone.

For example, if your idea is a chatbot that answers any business question, make one only for a single product from your suite.

Next time

In Effective Delivery #20, Adam Polak will explain the ups and downs of doing 100% AI-powered development for the first time in a commercial project.

That’s it for today ✌️

Read our most popular issue next

Published with a smirk by The Software House

Twarda 18, Warsaw, Poland

tsh.io →

It was created by our senior technologists who’ve seen how strategic team management raises delivery performance by 20-40%.

🔔 +121 subscribers in February! We appreciate you! Thank you for your trust.

TL;DR

• Individual departments struggle to collaborate on AI PoCs,

• Managers discover flaws in their AI plans too late,

• A 12-item checklist helps assess AI readiness,

• Find out what you lack to minimize the risk of failure.

Contents

1. Why AI PoCs fail

2. The AI readiness checklist

3. Interpreting the results

Hello! Aleksander Patschek at your service.

I am a Solution Architect at The Software House.

According to MIT’s 2025 report, 95% of gen AI pilots fail to deliver ROI.

Technology is not the problem.

Companies simply start software projects beyond what they can afford.

The mistake executives make is believing that building AI features looks exactly the same as regular development features.

I’ve co-launched 11 AI PoCs, and I’m here to warn you that they’re not the same.

I designed a checklist to help you identify flaws in your AI preparation before you invest.

Why AI PoCs fail

A non-AI feature often requires only your IT team.

An AI feature often calls for coordination across departments that rarely work together.

• Legal must determine what data can be sent to AI providers,

• Data teams must ensure information is clean and accessible,

• Governance must create rules for AI usage,

• IT must implement the solution.

If any department is not ready, the project may fail.

The AI readiness checklist

In my experience, successful AI pilots start from an audit of internal AI capabilities.

Unfortunately, many managers rush their projects, skipping the audit or missing key areas.

My checklist covers all the essential areas while remaining short and sweet.

Find out if the AI initiative you have in mind is likely to succeed or something to give up on now, before it wastes time and money.

Business

1. Our AI initiative solves a real user need

There’s evidence that users are tired of AI features.

Just one report suggests 35% of users don’t want AI on their devices (Circana, 2026).

Ask users whether they need AI and where it could improve their work.

You can use methods such as:

• user interviews,

• surveys,

• data analysis.

Many AI success stories come from relatively simple use cases, such as document processing.

Such projects focus on automating processes that users or employees find tedious.

2. Our internal processes are well-organized

AI can speed up a process only if it’s well-organized to begin with.

Processes that involve a lot of repetition are AI-friendly, while multiple exceptions and edge cases make it hard for AI to account for different scenarios.

Talk to the people actually doing the work to understand how the process functions, not just how it looks on paper.

Data

3. The data required for the AI initiative exists

Features like document processing often require minimal historical data, as AI mostly works with incoming documents.

But if you receive invoices in unusual formats, you need historical examples to train the AI to extract information.

Similarly, chatbots often require huge amounts of data because AI must accurately answer company-specific questions.

Ensure you have the data that fits your needs.

4. There is sufficient data

The chatbot example shows that sometimes you not only have to ensure that the data you need exists, but also that there’s enough of it.

At other times, you may find that the data you seek is potentially available, but extra effort is required to obtain it.

For example, if the process knowledge you seek exists only in employees’ heads, document it.

5. The data is clean and actual

Out-of-date data will make AI provide outdated answers.

Data must also be organized and accessible, ideally in a single location, such as a data warehouse.

If your data is scattered across systems, organize it before starting AI development.

Human resources

6. Engineers know how to use AI

Implementing AI requires specialized knowledge that goes beyond basic prompting.

Your engineers may need to work with vector databases and perform retrieval-augmented generation or agentic orchestration.

Fine-tuning models often requires machine learning experts rather than regular backend developers.

If AI development is a one-time project, partnering with an experienced software company may cost less than upskilling or hiring.

Your developers may also acquire expertise from working with them.

7. Employees have a positive attitude towards AI

People sometimes fear AI will replace them, so they resist adoption.

Remind them that AI can’t automate all of their work.

Instead, it will speed up a lot of it, making their lives easier and improving their productivity.

As such, they are much better off using it to the fullest.

If they don’t, another human willing to use new tools will take their job instead of AI.

Infrastructure

8. The AI POC can use the cloud

Cloud providers make AI implementation easier by handling model deployment, maintenance, and low-latency responses.

Your IT team then focuses on business logic rather than infrastructure management.

Go for the cloud if there are no good reasons not to.

9. On-premise trade-offs are acceptable

Some regulations or company policies force data to stay on-premises.

The best AI models from OpenAI, Anthropic, or Google aren’t available as open source.

Open-source alternatives have smaller context windows, more hallucinations, and lower-quality answers.

One client had strict data-residency policies, which forced them to use on-premises infrastructure for AI.

When tasked with extracting data from financial documents, the smaller on-prem models produced lower-quality results than expected.

The project was abandoned after the proof-of-concept.

If you have to use on-prem infrastructure, target simple tasks that smaller LLMs can handle.

Governance

10. Documented AI usage rules exist

Employees often use AI tools like ChatGPT without the company’s guidance.

They send sensitive customer data, proprietary code, or confidential business information to external AI providers.

You should have a rulebook that covers:

• What AI can be used for,

• What data can be sent,

• Which company subjects (e.g., internal projects, expertise, or secrets) are off-limits for any AI-based initiative.

11. The AI initiative is backed by legal

Some data requires anonymization before sending to AI, while other data may be entirely prohibited from leaving your systems.

Talk to your law department at the earliest stage of the AI initiative.

They can easily block any initiative, so getting their approval early prevents wasted development time.

A client discovered mid-project that their legal team would not approve the release.

The AI feature violated data processing contracts with customers

Six months of development were wasted.

Metrics

12. Baseline KPIs exist for comparison

Having data on how fast processes run makes it easy to prove if AI implementation was successful in speeding them up.

You might find that document processing improved by 50% while another area showed only a 10% improvement.

If you don’t have such KPIs, check if you can add them before you go through with your AI plan.

Interpreting the results

Don’t look only at how many times you thought “yes”.

You can score perfectly on business items but have no usable data.

If you have no organized processes or data, and your law department knows nothing about AI, stop your initiative and prepare your business first.

If processes are mostly organized and you have usable data, start a small AI pilot.

If none of the issues raised in the checklist stop you, you may be ready for a major AI initiative.

But you probably know that already.

Next time

I will explain how to approach AI product development based on your readiness level.

Thanks for reading today 👋

Have you read this record-breaking issue?

Published with a smirk by The Software House

Twarda 18, Warsaw, Poland

tsh.io →

It was created by our senior technologists who’ve seen how strategic team management raises delivery performance by 20-40%.

TL;DR

• Our AI-driven development framework introduced a single flow for all engineers,

• It’s called copilot-collections, and it’s used by 220+ developers,

• Developers using the framework became 30-40% more productive,

• You can use copilot-collections to deliver features days faster.

Contents

1. Why we built this

2. copilot-collections under the hood

3. How to use copilot-collections

4. Get the repo

Hello! Adam here.

Many IT departments gave developers AI coding tools, but saw no productivity gains.

From what I’ve noticed, 90% of teams fail to use AI effectively.

I believe one of the main reasons is that, when given total freedom, each engineer uses AI in their own way.

As a result, every one of them gets a different productivity boost.

Together with 11 engineers, I built copilot-collections to introduce a consistent AI workflow that everyone can use to achieve a baseline increase in efficiency.

Why we built this

Most companies give developers an AI tool and say, “Use it”.

Some engineers use AI efficiently, like a coding partner, while others treat it just like a search engine.

Many developers end up using different coding configurations for AI or even different models of it.

Inconsistent productivity is the result.

• AI champions improve efficiency even 200%,

• Frontline developers see little to no gain,

• Knowledge stays with the power users.

copilot-collections is an AI-driven development framework that levels out the gains by providing a standardized workflow.

In my organization, it provided an average productivity boost of 30-40% for developers who used it compared to when they didn’t.

copilot-collections under the hood

copilot-collections, which we’re now sharing for free, is a virtual delivery team that mirrors how we deliver at The Software House.

It’s built around GitHub Copilot and ties multiple tools (VS Code, Jira, Figma, Context7, Playwright, and Sequential Thinking) into a consistent workflow.

The 4-phase delivery workflow

1. Research

Prompt: /research

Copilot builds context around a task and sources related information.

2. Plan

Prompt: /plan

It creates a structured implementation plan with clear acceptance criteria.

3. Implement

Prompt: /implement

It executes against the agreed plan from phase 1.

4. Review

Prompt: /review

It performs a structured code review and automatically introduces bug fixes.

Each phase uses artifacts created by the previous phase.

For example, task summaries from the Research phase are used during the Plan phase to create a checklist of actions to perform later.

The extended frontend delivery track

For frontend tasks, we added 2 more phases:

• Review UI (/review-ui) focuses on verifying UI implementation against Figma designs.

• Implement UI (/implement-ui) performs iterative verification with Figma for a pixel-perfect implementation.

The 6 AI agents

When you add the two extra phases from the frontend workflow, copilot-collections offers 6 AI agents:

1. Business Analyst

Extracts and organizes knowledge from Jira and other sources, asking questions to clarify any ambiguities it encounters.

2. Architect

Creates the solution’s blueprint that can include components and interfaces, architecture sketches, and integration strategies.

3. Software Engineer

Writes and refactors the code following the agreed plan.

4. Frontend Software Engineer

Specializes in UI implementation with design verification.

5. UI Reviewer

Verifies the implementation against Figma designs and reports mismatches ranked by their severity.

6. Code Reviewer

Performs structured code reviews and risk detection.

The framework is built around VS Code.

In our experience, it works best with GitHub Copilot.

MCP integrations connect it with Atlassian, Figma, and Playwright.

How to use copilot-collections

We use copilot-collections in about 70% of our projects now.

Here are our best practices.

Help the agent generate requirements

The workflow is built so that the agent, either the Business Analyst or the Architect, will ask you extra questions to clarify the information gathered from tasks and other sources.

Answer the questions to help improve the requirements generated by the agent.

For best results, treat the agent as your partner rather than a servant.

Always verify the results

Focus especially on the outputs of the Research and Plan stages.

Any gaps in the proposed solution or project knowledge are much less costly to remove when caught early.

Use Copilot Instructions

The agent and prompts of copilot-collections give you a consistent AI development workflow.

However, code quality depends more on Copilot Instructions.

They serve as coding guidelines and can be customized for each project.

Prioritize repetitive features

Features such as user authentication, user management, and role assignment are ideal for this framework.

These features have recurring requirements that our AI framework has already analyzed.

If your backlog contains well-defined acceptance criteria, the framework can deliver such features with minimal intervention.

Since standard features are easier to describe and AI models already know them well, we could write clear requirements for building them.

As a result, we can now develop complete user management systems in a few hours instead of days.

In the near future, we’re planning to further improve the development of repetitive features by extending the framework with Agent Skills.

Through Skills, agents will gain on-demand access to specific expertise.

For example, you will be able to build a Skill dedicated to developing a payment processing system.

Try it for greenfield projects

The framework is really good at building features and applications from scratch (so-called greenfield apps).

Existing codebases add extra context, making analysis harder.

Modernization projects can still work, but require quality requirements and oversight.

Assign experienced overseers

Knowledge base, instructions, or Agent Skills won’t fully replace experienced engineers who have lived through real-world troubles.

It’s best to have them oversee the work.

We used copilot-collections to migrate from legacy to microservices.

AI sometimes suggested workable but not cost-optimized solutions because it didn’t understand the full business context.

Experienced engineers asked AI questions to help it find better solutions.

Customize or replicate our framework

You can customize our framework with new agents and prompts.

If you use a code editor different than VS Code, such as Cursor or Kiro, you can still recreate the same workflow.

Most of copilot-collections’ agents and prompts can be replicated elsewhere.

Get the repo

Access copilot-collections on GitHub. It has 64 stars so far!

Next time

Aleksander Patschek will provide a checklist to assess your company’s AI readiness and find the right approach for starting an AI project.

Thanks for reading today ✌️

Published with a smirk by The Software House

Twarda 18, Warsaw, Poland

tsh.io →

It was created by our senior technologists who’ve seen how strategic team management raises delivery performance by 20-40%.

TL;DR

• IT managers should answer 80% of project questions without asking their team

• Context switching caused by constant questioning kills developers’ productivity

• Managers who lack project awareness cannot secure long-term efficiency

• Backlog, repositories, and pull requests contain most answers one could need

Contents

1. Low project insight vs delivery speed

2. Questions managers should answer alone

Greetings! 🫡

Adam here.

How often do IT managers say something like “I don’t know, but I’ll ask the team”?

15 years in IT taught me that relying on your engineers for answers negatively impacts delivery.

And it goes far beyond distracting them from work.

If you don’t want to slow down your team because of poor project knowledge, you should be able to answer 80% of project questions on your own.

“(...) a programmer often spends a significant amount of time (i.e. 15-30 minutes) reconstructing working context before resuming interrupted tasks.”

Abad et al., 2018, n=132

Low project insight vs delivery speed

The negative effects of questioning begin the moment you ask the team something you should know.

Short-term impact

Each question to a developer costs more than you can imagine.

Nothing ever costs just “a minute” of their time.

Interrupted engineers stop coding and jump through browser windows to return an answer ASAP.

Then, they still need the mental strength to refocus on their project.

It’s worse when a question creates a chain reaction.

You definitely experienced this:

• You were asked a question

• You passed the question to another developer

• That developer passed it to another person

So, 1 question can steal the time of 2 more people.

Needless questions also have a way of extending meetings, further draining the team’s effectiveness.

Our client regularly held daily standups that lasted 1 hour or more.

After a review, we found that one of the managers asked each developer to present what they did yesterday.

He would have saved everyone a lot of time if he had just reviewed the board.

Long-term impact

IT managers with poor project knowledge catch delivery problems way too late.

One of our Engineering Managers trusted his team so much that he skipped metric reviews.

After 2 months, he discovered the project was 3 months behind schedule.

Metric analysis tools were available but unused.

It was too late to avoid a delay that hurt many stakeholders.

While I believe in team autonomy, nothing says trust should be unconditional.

This manager should have:

• never relied on the IT team’s estimates indefinitely,

• reviewed lead and cycle time every few days to confirm the team’s claims.

Questions managers should answer alone

As a CTO, I teach our EMs to dig into project data instead of disrupting engineers.

Here’s how to answer 80% of the most common stakeholder questions.

1. What is the current status of this feature?

Let’s un-teach people to ask this in favor of self-reporting.

The answer

The task tracker holds it.

In particular, you can find it in a well-maintained backlog with clear task visibility.

Look at when the task was updated, and who owns it in JIRA, Linear, or Trello.

Responsible IT managers review the backlog at least every few days to spot any delivery blockers.

2. Are we on track to deliver on time?

Predicting development delays costs less than a last-minute realization that affects the timeline and the budget.

The answer

Cycle time and lead time metrics have it.

Velocity counted with story points is unreliable, as IT teams can estimate the same job differently, manipulating the numbers.

Cycle time and lead time measure the actual delivery time and cannot be gamed.

Review them every few days.

The earlier you spot a negative trend, the faster you can intervene.

You can also connect your tracker to an AI to automate the analysis.

We tested this internally, and it works well for quick status checks.

However, AI should supplement your knowledge rather than replace hands-on involvement.

3. What technologies does the team use and why?

Stakeholders inevitably ask about compatibility, constraints, and technical capabilities.

The answer

When joining a new project, any IT manager should have access to:

• a task tracker,

• repositories,

• design tools like Figma,

• the knowledge base like Confluence or Notion.

Having that access, you can check the repository structure and package files for dependencies.

Then, review the architecture documentation.

Try to understand how engineers chose these technologies and what alternatives they considered.

4. What problems or blockers are there?

You can only guarantee the project timeline is valid if you know what issues exist and how much time they might cost.

The answer

Daily standups are a good opportunity to reveal any blockers.

Walk through the board of your tracker column by column instead of asking the 3 standard questions of what you did yesterday, today, and what obstacles you see.

Pair programming is another great way to spot potential project derailment early.

If you see a developer struggling, code with them to learn about the blocker firsthand while helping to resolve it.

You could see 30% faster Lead Time

I (Adam) and my crew help engineers become AI-for-code veterans. In 30 days.

How does this work?

5. How was this technical problem solved?

Understanding implementation decisions helps you answer follow-up questions and guide future work.

The answer

Pull requests have it.

Make it a habit to review what gets merged into the main branch.

Filter by merged PRs from the past few days and scan descriptions and changes.

You don’t need to review every PR in detail.

Focus on PRs that touch critical parts of the system or implemented features you need to understand.

By reviewing PRs regularly, you learn how the team solves problems without asking.

What’s more, code reviews can help an IT manager who rarely codes stay up to date with implementation practices.

6. Why do we need this feature?

Understanding the “why” helps you make better technical decisions aligned with business goals.

The answer

Product documentation, stakeholder conversations, and project briefs hold this context.

Analyze it against industry benchmarks and reports to find out how the product compares to competitive ones, and where it fits in the market.

7. What does this requirement mean?

Sometimes, “I’ll ask the team” morphs into “I’ll ask the stakeholder”, which usually presents the manager as a disconnected one.

The answer

It’s in all the meetings, like a project kick-off, and workshops you hold with your client.

Ideally, you should understand every client requirement when it is first presented to you.

Ask questions only when needed.

If there’s something unclear to you, assume that it will also be unclear to your teammates.

At a minimum, understand the requirement before you pass it to the team.

Next time

Aleksander Patschek, one of our main AI experts, will demonstrate how to verify whether your company has the resources needed to develop AI-powered products.

Have a good one 👋

Published with a smirk by The Software House

Twarda 18, Warsaw, Poland

tsh.io →

It was created by our senior technologists who’ve seen how strategic team management raises delivery performance by 20-40%.

TL;DR

• As a Deputy Head of Development, I co-manage 15 Engineering Managers (EMs),

• They all have 6 critical skills in common,

• Use my questions to screen potential EMs for their suitability.

Contents

1. Recognize the 6 traits

2. Questions to ask

🎊 Happy New Year!

Marcin here.

Last time, I explained when hiring an Engineering Manager makes sense.

An EM helps maintain efficient delivery when developers struggle to self-organize or metrics slip.

But this position requires a person of a specific character.

And it’s not necessarily the best engineer on the team.

Today, I’ll explain what I look for in an EM to avoid selecting an absent manager.

Recognize the 6 traits

The EM role demands more than a job title.

Some EMs never manage to boost development efficiency.

Then, they quickly realize that they don’t like that new role.

Here are the traits of an EM who loves their job but is loved back by the team.

1. Natural mediator

Many developers rarely share their observations.

They see a colleague delivering buggy code, but say nothing because criticizing feels uncomfortable.

You need an EM who is a feedback culture builder.

A good EM can empower developers with a communication style based on a framework such as FECE (Facts, Emotions, Consequences, Expectations).

FECE works as follows:

1. Facts

A teammate states an observed behavior.

2. Emotions

They go on to share how they were affected by it.

3. Consequences

They detail the implications of the behavior.

4. Expectations

They define the desired change.

Teams allowed to communicate this way refocus from blaming to looking for improvements for everyone.

2. Team unifier

Once people communicate openly, the EM can shape them into a cohesive unit.

A good EM functions like a sports coach.

They should have a good overview of the project beyond their field of expertise and assign tasks based on the strengths of the team members.

With an EM onboard, everyone can take equal responsibility for delivery.

Without one, developers work in tunnel vision, ignoring others’ tasks.

We promoted a strong developer into the EM role for a challenging project.

Despite the label, the person focused on architecture and functioned as a de facto lead developer.

One-on-ones happened rarely, and communication was siloed.

Eventually, they admitted that EM’s work was not what they wanted.

3. Information broker

The third trait is the ability to stay closely involved with the project.

In one project, managers skipped dailies, refinements, and code reviews.

They advised without understanding the current context, based on their experience from previous projects.

We added an EM who went deep into the codebase, eventually introducing changes that positively impacted delivery.

Being hands-on lets the EM introduce metrics that matter.

Measurements like lead time become meaningful only when one understands what influences the delivery time of each phase of the development cycle.

4. Change champion

Developers rarely have the regular time to self-improve.

An EM can support their growth as a micro-enabling team

They’re responsible for introducing new languages or frameworks and leading their adoption in line with business requirements.

I’d also expect that an EM can work through the resistance veteran engineers can have by being an accessible coding buddy.

5. Talent developer

Not every developer knows in which direction they want to go.

An EM helps each person find their path in a way that aligns with the organization’s goals.

For example, if a developer wants to try public speaking, the EM may suggest an internal lightning talk as a first step.

Turnover rate drops for teams with a manager who actually implements growth plans.

6. Trusted listener

In remote environments, developers often lack someone to discuss personal matters with.

An EM supports team members through difficult periods via one-on-ones.

They should be a trusted person who can listen without judgment.

Team members who feel heard are less likely to think about leaving.

When turnover decreases, institutional knowledge remains with the team for longer

Questions to ask

An introverted engineer who volunteers to be an EM probably won’t handle the weight of this role

The right candidate will more likely be already an ever-present supporter and the advisor of choice for many colleagues

I’d recommend using these 6 questions to vet out contenders.

1. How do you handle giving difficult feedback to a teammate?

2. Why (or why not) do you feel a sense of belonging with your teammates?

3. How do you stay up-to-date with the team’s daily activities?

4. Have you ever introduced a new practice in the department on your own?

5. How do you identify growth opportunities for people who don’t speak up?

6. What do you do when you sense someone struggling?

Each question refers to the specific trait explained above.

Record the candidate’s answer, and compare it with the descriptions from this issue.

Next time

Adam Polak will return with EDN#16.

He wants to tell you why any IT manager should be able to answer 80% of project questions without bothering their engineers.

Could you?

Anyway, I appreciate your time today 🙇

I’m wishing you an emptier work calendar in 2026.

Published with a smirk by The Software House

Twarda 18, Warsaw, Poland

tsh.io →

It was created by our senior technologists who’ve seen how strategic team management raises delivery performance by 20-40%.

TL;DR

• An EM transforms disconnected developers into a strong Spec Ops unit,

• EM’s role didn’t exist 15 years ago, but is now essential for many IT departments,

• Some organizations struggle to separate EM and PM responsibilities,

• Use these 7 practical scenarios to decide if an IT organization needs an EM.

Contents

1. The rise of the EM

2. What an EM actually does

3. Do you need an EM?

Hello!

I’m Marcin Basiakowski, presenting my first piece for Effective Delivery.

I’m the Deputy Head of Development.

Previously, I was the Head of QA at The Software House.

Beginning this year, my organization has transformed all team managers and some department heads into Engineering Managers (EM).

As a result, I had the chance to work closely with EMs.

Many IT leaders notice the EM role appearing in job listings and wonder if they are missing out.

Well, are they?

The rise of the EM

When I started in IT 15 years ago, EM’s role didn’t exist.

Everyone was sorted into silos based on their skills.

At TSH, we had several departments, such as QA, frontend, Node.js, or PHP.

• Each manager was responsible only for their own layer,

• This created friction because no one owned the whole development process,

• When technical issues showed up, the communication devolved into a blame game.

The frontend and backend would see each other as the cause of inefficiency.

At the same time, the QA team was accused of inflating the number of bugs to raise the defect count.

It was hard to improve IT efficiency because these siloed teams lacked shared productivity goals they could strive for together.

The EM role resolved the lack of cooperation between members of an IT team.

What an EM actually does

The EM is a technical manager responsible for:

• code quality and technical standards across the entire team

• team composition and ensuring the right mix of skills

• setting clear technical goals for the team and tracking overall productivity

• representing the development team’s interests to stakeholders

• proposing process changes that balance business needs with technical sustainability

• individual growth and career development of each developer

• performance reviews

Many organizations expect their product or project managers to handle these tasks.

Let’s examine when it is possible, and when an organization needs an EM instead.

Do you need an EM?

1. PM’s technical skills

If a product or project manager lacks technical depth, they will struggle to discuss architecture, code quality, or process improvements.

In this case, an EM is a better choice for these tasks.

However, if your PM has strong technical competencies, they can handle these conversations themselves.

I know cases where 1 technically oriented PM led several product teams without an EM.

2. IT team’s maturity

If the feature team has many juniors and mid-level developers, an EM will become their guide and a valuable mentor.

It’s almost impossible not to see any improvement in delivery with an EM.

Some teams with experienced seniors might be able to self-organize.

3. Measured underperformance

If IT’s efficiency metrics, such as lead time or deployment frequency, are declining, an EM can help address these issues.

If you don’t measure IT’s productivity at all, an EM is the one that could introduce systematic measurement of key productivity metrics.

But if IT tracks productivity metrics, and they stay healthy as ops scale, you might be fine without an EM.

4. The organization’s size

There’s no team-size-to-EM ratio that warrants hiring one.

Still, the CTO should know if they can ensure development efficiency.

That’s a good reference point.

If a CTO finds themselves unable to improve IT’s output directly, an EM can take over this responsibility.

At smaller companies, frontline CTOs can handle this without an EM.

5. Hiring plans

When IT plans to scale up or create multiple new teams, bringing in an EM is a good idea.

They’ll build a strong foundation for effective delivery.

In 1 project, our team faced a tight deadline.

They needed to improve their delivery performance to meet it.

The project had an EM from the start, who changed the team’s composition to better respond to the new requirements.

They continued to rally them around shared goals, bolstering morale.

His efforts boosted the team’s delivery by 100% over 4 sprints.

If IT size remains stable in the future, an EM may not make a significant difference.

6. No self-improvement within IT

Many IT teams are stuck in a cycle of continuous delivery — but without any self-improvement.

An EM can guide them out of this cycle.

But if engineers find time for retrospectives and process improvements, they might not need external help.

7. The budget

An investment in EM pays off through faster delivery and better quality in the long run.

Yet, I see that companies on a tight budget are tempted to choose 3 developers over 2 developers plus a manager.

This choice can backfire, but it won’t happen immediately.

Quite often, development remains stable, but there’s no quality improvement.

And that’s what an EM can ensure of.

One of our clients chose to pay for more developers instead of an EM.

They thought it was a money-wise decision.

The project kept struggling with process issues that nobody had time to address.

As the story shows, stacking up engineers won’t help if nobody has time to fix the process.

Next time

If at least 4 of the 7 factors for hiring an EM is true, I’d recommend introducing one.

But how do you know a candidate is a fit and not an imposter?

I’ll explain what makes an Engineering Manager great in the next issue.

Catch you in 2 weeks 👋🏻

Published with a smirk by The Software House

Twarda 18, Warsaw, Poland

tsh.io →

It was created by our senior technologists who’ve seen how strategic team management raises delivery performance by 20-40%.

TL;DR

• There are 4 levels of AI for code adoption that reflect the team’s efficiency,

• IT Managers can only see real productivity gains at level 3 and above,

• Removing the 7 blockers described in EDN#12 can get IT to stage 4,

• Measure engineers’ AI adoption by studying token use.

Contents

1. The 4 levels of AI adoption

2. Remove the 7 blockers

3. Measuring success

Hello! Adam here.

Last time, I described the 7 blockers that prevent IT departments from seeing productivity gains from AI tools.

At TSH, our AI adoption started at just 10% of engineers actively using AI for code.

After we addressed the blockers, that number grew to around 70%.

Here’s how IT managers can help their engineers max out AI-powered productivity.

4 levels of AI-for-code adoption

You may remember these from the last issue.

As I explained, seeing measured improvements from using AI coding tools can be seen only at level 3.

Help your IT department eliminate the blockers, and engineers will master AI-for-code faster.

Remove the 7 blockers

1. Switch to the “Agent” mode

Removes blocker 1: using AI as Stack Overflow.

The fix requires one click in the AI tool.

Tell developers to switch from “ask” mode to “agent” mode.

• Ask mode only answers questions,

• Agent mode pushes AI to return technical solution instead of chit-chatting,

You can also recommend tools that only work in agent mode, like Google Antigravity.

Verify if engineers made the switch in 1-on-1’s, where you show how to use it.

2. Preload AI with architecture know-how

Removes blocker 2: using AI without a clue.

Juniors without architectural experience can still use AI effectively with some safeguards.

At lower levels, the most cost-effective option is to have humans review their work.

At level 3, you can pre-load the AI assistant to have access to detailed guidelines regarding the architecture with :

• Jira task information,

• Github Copilot instructions / spaces,

• Cursor rules,

• Claude’s Agent Skills.

At level 4, you can create digital versions of your best architects that assist in generating code.

This is an advanced solution that requires you to assemble a wide understanding of an architect’s skill set and approach, documenting, and mapping to create an AI agent.

3. Help developers grow their AI skills

Removes blocker 3: lack of training and knowledge sharing.

Lightning sessions were the most efficient AI upskilling method we’ve introduced.

These are 45-minute video presentations we hold every 2 weeks.

I encourage our engineering champions to share whatever they have learned with all of our company.

Lightning talks should serve as a necessary introduction to AI-first development.

Access to self-learning courses for developers is a good next step.

However, for most mixed-experience feature teams, forming a 1-2 people enabling team is what brings lasting change.

• Choose your strongest AI adopter,

• Offer them time and resources to upskill other engineers,

• Ask them to focus on code reviews and pair programming.

4. Support your AI expert

Removes blocker 4: no champions to drive adoption.

Verify which engineer uses the most AI tokens.

They’re potentially your champion who can standardize AI prompts to increase the team’s velocity.

If none of the engineers cuts it (which would be an anomaly):

• find one externally,

• hire a consultant,

• educate the most curious teammate.

5. Standardize AI coding tools

Removes blocker 5: no standardization of tools and practices.

Limit your choice of AI coding tools to just a few so that:

• your engineers can master them over time,

• there’s still some flexibility in choosing the best AI for a project.

We use GitHub Copilot or Cursor, and each project uses only one.

We initially used a lot of tools, which made it hard for developers to master any of them.

We established an enabling team to find the most promising AI tech that could boost delivery.

Our model recommendations evolved from Sonnet 3.7, to Sonnet 4.5, to Opus 4.5 based on systematic comparisons.

6. Introduce spec-driven development

Removes blocker 6: No AI-first development workflows.

Spec-driven development (SDD) is an approach to AI-assisted coding that maximizes the generated code’s quality.

I’d recommend it for creating workflows for jobs such as building new UI components or APIs.

We use SDD ourselves, of course.

To design an AI workflow with SDD at your organization, use a 3-phased approach for AI work.

Research

Connect AI to Jira, the codebase, and project documentation so that the bot can create better responses and code.

Planning

Ask AI to suggest the most optimal solution for implementation to review its logic.

Implementation

Once you greenlight the plan, order it to proceed with code generation.

How you load the project’s context into AI matters.

One of our feature teams used a 3,000-line instruction file to provide more context for an AI agent.

AI struggled to scan the file, so it kept looping and eating up tokens.

Without standardized prompts for the IT team, Managers shouldn’t hope to see a productivity boost.

7. Accept slow and steady progress

Removes blocker 7: unrealistic expectations about automation.

Too many people believe AI for code is like a plug-and-play tool that immediately pushes out near-perfect code.

That’s why IT managers and stakeholders avoid launching a months-long AI training program.

Even some of our respectable developers can’t grasp why Copilot can return vibe code.

AI was never meant to be perfect.

And using it well requires:

• building agents pre-loaded with documentation,

• creating unified prompts for the entire feature team,

• upskilling IT through one or many AI champions.

Like with any other technology, success comes in small steps.

We set up a Figma-to-code workflow that translated designs into ready-to-use code.

The overall development time dropped significantly.

Still, Designers were disappointed they had to build UIs differently for the workflow to work.

Remind your developers that AI for code can’t automate their work fully, so they shouldn’t give up on it.

Highlight the small productivity gains the team reaches thanks to AI tools.

Over time, people will feel empowered to raise their work efficiency.

Measuring success

See if IT is moving through the 4 adoption levels by:

• measuring the team’s baseline productivity with:

  • Lead time

  • Cycle time

  • Deployment frequency

  • Production bugs

• monitoring AI token use vs subscription limit per team or person,

• reviewing the change in cycle time and velocity post-implementation.

Help IT Reach 30% Faster Delivery With AI

Connect engineers with me, Adam, and my crew for 30 days. See improved lead time.

How does this work?

Next time

I’m happy to announce my pal as our next issue’s author.

Marcin Basiakowski, our Deputy Head of Development, will philosophize the usefulness of Engineering Managers (uh-oh).

You’ll learn when a team can act like a bunch of unguided preppers, and when an EM can guide them across the roadmap with Swiss precision.

Thanks for reading today ✌️

Published with a smirk by The Software House

Twarda 18, Warsaw, Poland

tsh.io →

It was created by our senior technologists who’ve seen how strategic team management raises delivery performance by 20-40%.

TL;DR

• AI coding tools promise improved delivery efficiency, but most IT teams see no gains

• IT managers rarely implement AI-for-code tools correctly

• 7 blockers prevent IT from adopting AI for code

• According to Adam, a CTO overseeing 220+ technical professionals, companies go through 4 levels of AI adoption

Contents

1. Why managers can’t see AI productivity

2. The 7 AI implementation blockers

3. The 4 levels of AI adoption

Hello! It’s Adam.

Every week, a client tells me their developers use AI tools like Copilot or Cursor.

Then they admit they see no measurable productivity improvement.

What’s going on?

Even among 30 of our current clients, only 2 of them manage to deliver faster with AI coding tools.

The harsh truth is that most IT departments fail to implement AI effectively.

Their leaders believe that merely providing access to AI tools is sufficient to enhance IT productivity.

In this issue, you will learn why this isn’t the case at all.

The next edition will provide you with practical steps to avoid the mistakes companies make when introducing AI coding tools.

Why managers can’t see AI productivity

You’d be surprised how many IT departments are unaware of their cycle time or lead time.

They often have no data on how long features take to ship, how frequently they deploy, or even the number of production bugs they find.

That’s the foundation for measuring any AI adoption.

We had a client who allowed Copilot to be used across their team.

Everyone used it in their own way.

Ultimately, they could not see any productivity difference.

Most developers were not using AI effectively.

Some never even started using it.

They only knew this because they measured cycle time.

Without access to metrics that signal IT productivity, you can’t verify whether the AI code tools you’ve introduced have succeeded in improving them or not.

The 7 AI implementation blockers

Even if IT measures development productivity properly, it may still struggle to use AI by the book.

Here’s what to watch out for.

1. Using AI as Stack Overflow

Most developers ask AI to explain code rather than generate it.

They copy snippets and paste them into their editor.

This represents basic usage where AI acts as a more effective search engine, providing a more automated alternative to Stack Overflow.

This doesn’t speed up work nearly as much as using AI to write code from scratch.

2. Using AI without a clue

Most IT Managers assume developers can delegate work to AI without understanding system architecture.

This creates unmaintainable code that looks functional but breaks under scrutiny.

A client came to us with a vibe-coded mobile app requesting a simple fix before their demo.

During testing, we discovered the app barely worked.

The client wasn’t able to explain why things were this way.

The client knew what they wanted to build, but had no idea how to make it properly.

Nobody verified whether the technical approach made sense.

When problems appeared, they didn’t know how to rebuild it.

3. Lack of training and knowledge sharing

Companies often assume developers will self-educate after hours.

But the uncomfortable truth is that effective training requires dedicated time and expert guidance.

At TSH, we once told teams to use AI and assumed they would figure it out.

Power users we knew had gains immediately.

Everyone else in the company did not.

Some time later, it turned out others simply weren’t using AI at all.

Everyone else struggled or gave up.

4. No champions to drive adoption

You’re not going to provide quality internal training if you don’t have power users of AI tools to begin with.

These are not easy to come by.

The best AI users learned through trial and error.

They spent weeks figuring out the right prompts and how to use them in practice.

That knowledge never spreads without intervention.

5. No standardization of tools and practices

When there are no standardization roles for AI tool usage, chaos follows:

• Companies use as many as 50 different tools.

• Developers use whatever they want at any given time.

• They switch randomly when new tools appear, never mastering any one thing.

In the next edition, I’ll show you why the most crucial matter is not at all what tool you’re going to pick.

6. No AI-first development workflows

Most companies never establish AI-driven workflows for general use.

Instead, they give developers AI tools but no supporting infrastructure.

At TSH, we configured environments, such as our coding editors and Figma, to enable AI to access all project files.

Without this setup, developers would have spent half their time manually copying context.

That defeats the entire purpose of automation.

In the next edition, I’ll show you what kind of AI-driven workflows you can build to really speed up your team’s delivery.

7. Unrealistic expectations about automation

Some managers who introduce AI coding tools set themselves up for disappointment because they simply expect too much from them.

They often believe that providing developers with such tools delivers instant productivity gains of 30% or even 100%.

This plug-and-play mentality ignores the learning curve these tools require, leading to all the other pitfalls I’ve described.

The truth is that AI is unlikely to automate 100% of development work anytime soon.

I’ve also interacted with developers who are disappointed that AI can’t complete a coding job from A to Z even though it completes 60% of the task.

They also need to hear that their expectations are too high.

It’s a tool — not an android.

The 4 levels of AI adoption

My experience as a CTO who helped introduce AI coding tools for 220 technical employees taught me that there are 4 stages of adoption.

Level 1

Developers choose their preferred AI without coordination.

Level 2

Leadership narrows down AI selection to strengthen adoption and launches formal training.

Level 3

IT managers introduce best practices for given AI-for-code tools through EMs or Team Leads who measure success in cycle time.

Level 4

IT switches to AI-first development where AI increases work efficiency at each SDLC stage.

Like I said, I see that IT departments that don’t see AI gains never mature beyond level 2.

Only organizations at level 3 or 4 can see measurable wins in delivery speed.

Next time

Feeling like IT at your organization hasn’t milked AI yet?

Learn from EDN#13 how to push for AI-assisted development successfully by avoiding my own mistakes.

You’ll see 7 solutions to the 7 blockers you’ve learned about today.

Thanks for reading today ✌️

Published with a smirk by The Software House

Twarda 18, Warsaw, Poland

tsh.io →

It was created by our senior technologists who’ve seen how strategic team management raises delivery performance by 20-40%.

TL;DR

• Managers choose processes over trust because metrics are easier to show,

• Teams optimize for process compliance instead of delivering features,

• IT managers can rebuild ownership by removing approval steps,

• A client required developers to self-test without QA… and no. of bugs sunk.

Contents

1. A new process is like a painkiller

2. How process worship destroys collaboration

3. Strategic process removal

4. Signs of growing ownership

Hey there.

Andrzej here again!

In many IT projects I worked on, IT managers responded to delayed releases or production bugs by adding more processes.

They created approval flows, mandatory checklists, and pushed for new metrics.

IT teams stuck to these new processes perfectly, but the problems actually worsened.

Funny, huh?

These managers rarely invested time in fixing the core problems with engineers.

New development process rules only gave them an illusion of control.

I’d say there’s only one solution for that paradox.

Replace unnecessary processes with stronger ownership from the IT team.

A new process is like a painkiller

If you have a headache, you can pop a pill.

In reality, you stared at the screen too long or got dehydrated.

IT leaders lean towards quick fixes instead of deep teamwork because:

• building a culture of responsibility takes months of teaching developers to care about business outcomes,

• implementing a checklist from another project takes one day,

• process success is easy to measure

• they can prove that the team completes their story points every sprint.

Measuring real ownership presents a different challenge.

IT managers can’t put a number on developers caring about the product.

The results only become visible months later when the product works and brings in revenue.

Sadly, the issue of low team ownership can only be delayed, never avoided.

How process worship destroys collaboration

The approval bottleneck

One project had an approval flow that required 3 sign-offs for every deploy.

Product manager, QA lead, and a technical architect all had to approve.

Getting them to agree took days or even weeks.

The feature team might stop suggesting improvements when the added overhead is too restrictive.

One developer showed me a task to add a discount feature to the shopping cart.

He knew it would conflict with an existing system but built it anyway because “that’s what the task said.”

The synchronization problem

In one project I consulted on, engineers worked perfectly in line with the manager’s process.

Frontend was a sprint ahead, building forms without API endpoints.

Backend was a sprint behind.

Each team tended to their field instead of caring about delivery together.

Regardless, everything seemed fine on paper, as both teams hit their velocity targets consistently.

Task completion mattered more than business value delivery.

IT leaders cannot hope to overcome an isolation mindset without deeper involvement.

Gaming the metrics

Developers know exactly what gets measured and what gets rewarded.

A developer who needs to increase commit frequency will split one change into ten tiny commits.

The velocity chart then looks amazing, but work quality doesn’t improve.

What if a manager asks for faster code reviews?

Developers can skim through the code and hit approve.

Still, bugs will slip through.

I call this KPI-driven delivery, where metrics are more important than outcomes.

Sprint frustration

Retrospectives can often become rituals of frustration.

A feature team might keep listing the same problems each sprint.

If the process doesn’t allow any bottom-up changes, engineers will feel disempowered.

That’s when they drop initiative.

The process taught them that following instructions matters more than delivering value.

Strategic process removal

In my experience, IT managers can rebuild a culture of ownership in 3 to 6 months.

Here’s how one of our partners did it.

At an e-commerce company, Developers wrote code, and QAs tested it.

The client made a radical decision.

He taught developers to test their own code, then fired all the QAs.

2 months later, bug reports from users dropped to record lows.

Without the QA safety cushion, developers knew each bug would point back at them.

This forced them to care about quality in a way that no process ever could.

The client never hired QAs again because the team finally understood what taking responsibility meant.

Personally, I wouldn’t recommend such drastic measures.

Consider an alternative.

Month 1: Process audit

Audit all development processes and decide if each increases or decreases team responsibility.

Build up a list of such to simplify or remove.

Months 2-3: Building trust

Remove one approval step in the development process.

Grant developers permission to change implementation details without approval.

They’ll constantly ask for confirmation at first, but this behavior will fade as they gain confidence.

Months 4-6: Business thinking

Instead of asking “Did you complete those tasks?” try “How did the team’s work support the business this sprint?”

Feature teams need time to develop this new perspective, so give them at least 2 months of consistent practice.

Month 6: Increase feature ownership

We made a stream-enabled team responsible for features instead of separate tasks.

A form wasn’t considered done when the frontend looked pretty.

It was done when users could submit data successfully.

After a few sprints, team members started planning together and reviewing each other’s code regardless of their roles.

Signs of growing ownership

• Developers suggest improvements without being asked

• Lead time decreases without management’s intervention

• Bug counts drop without additional QA

• IT teams self-organize around problems

Next time

Adam Polak will return to expose why AI implementation for development teams often fails.

Apparently, giving developers Copilot access doesn’t automatically improve productivity.

Who would have guessed? 😏

Our own experience with rolling out AI tools for 330 technical employees will teach you how to do it right.

Thanks for reading today 👋

Published with a smirk by The Software House

Twarda 18, Warsaw, Poland

tsh.io →

It was created by our senior technologists who’ve seen how strategic team management raises delivery performance by 20-40%.

🔔 We’ve reached 100 subscribers because of smart readers like you! Thank you for keeping us employed!

TL;DR

• Successful PMs and EMs treat responsibility building as a continuous process starting from day one,

• Watch out for subtle signals where team members deflect ownership,

• There are 6 responsibility-building techniques to use throughout a project’s lifecycle,

• Distributing leadership across many team members prevents single points of failure.

Contents

1. Why collective responsibility is a myth

2. How team members dodge ownership

3. 6 tools to build team responsibility

Hey there! My name’s Jakub.

I’m the Delivery Manager at The Software House.

I started as an Agile Project Manager, and after 7 years between clients and feature teams, I’ve learned a bit.

Before writing this, I’ve been asked what the biggest lie about team responsibility in Scrum is, and why CTOs still believe in it.

Well, believing that IT teams act responsibly by default is that lie.

But they can. If they’re taught.

A developer can tell a stakeholder a task “isn’t important right now.”

The stakeholder could hear their feature doesn’t matter.

Seniors might watch the exchange without stepping in.

And if the PM is absent, projects might go into YOLO mode.

You’ve witnessed such situations, right?

In this issue, you’ll learn to spot signs of irresponsibility and how to build up the team’s sense of ownership without being controlling.

Why collective responsibility is a myth

Even when you form a new feature team, its responsibility must be grown through continuous effort across multiple sprints and milestones.

If that’s not done, delays, production bugs, cost spikes, or ignored support tickets shouldn’t be so surprising.

Let me simplify this:

• As a manager or a lead, your perspective centers on the stakeholder or the end-user,

• If they’re satisfied, you hope the project succeeds,

• In contrast, each engineer will think of the piece they add to the pile,

• Unless they’re specifically taught the business value mindset, they won’t feel like a part of a greater effort.

I’m not trying to criticize anyone.

People simply aren’t mind readers and want what is expected of them to be explained clearly.

If you want to see end-to-end ownership that goes beyond contracted tasks, invest way more time in discussions of what you want engineers to do.

Soon, you’ll learn the 6 responsibility-building techniques that will support the process.

But first, practice recognizing irresponsibility.

How team members dodge ownership

Several signs show a lack of shared project responsibility.

Blink, and you’ll miss them, as what’s being said or done might seem reasonable.

• “This isn’t important right now.”

Engineers who say this might be prioritizing their own tasks over the needs of stakeholders.

At the same time, their task might not offer the most value to the company.

• Explaining the code and not its impact

I’ve witnessed demos where the speaker explained what’s happening with the code as it was compiled on the screen.

300 lines of new code aren’t the point.

The potential frontend speed boost that improves the checkout rate is.

Help engineers grasp that stakeholders want to hear about the business value, not another report entry.

• “There was no ticket for that.”

This has a nice ring after the infrastructure fails overnight on the weekend.

Waiting for requests shows a fundamental misunderstanding of teamwork.

Ultimately, the feature team’s success ensures that each engineer keeps their role.

In a project I managed, cloud costs suddenly jumped by 7000%.

No one in the feature team noticed.

That’s because no one created a ticket for DevOps to set up project monitoring.

• Team members keep waiting for QA

In some of our clients’ projects, deployment would take weeks.

Unattended pre-deployment tests were one of the top bottlenecks.

Engineers hesitate to get involved in feature tests, but they should push for their completion in line with the DevOps mindset (build, test, maintain).

• Nobody challenges stakeholder requests

Businesspeople often have great insight into market dynamics.

But they really aren’t UX experts.

Frontend developers or Designers might hesitate to challenge requests or changes that could hurt the product experience, even though they know better.

6 tools to build team responsibility

1. Micro-reminders shared through Slack

Address any deflections in responsibility in real time instead of waiting for formal meetings.

Problems should be flagged before they occur.

In time, when the PM goes on leave or faces unexpected circumstances, developers will make fewer critical mistakes thanks to this training in proactive communication.

They will also feel obligated to uphold the development process.

For one project in the sensor industry, our feature team built a dependency map.

We used it to signal when our EM and PM would require a stronger presence of the client’s team in the project.

2. Demo ownership rotation

Encourage developers to explain what their code does in business terms during stakeholder demos.

It’s the IT manager’s duty to help team members explain how backend validations impact revenue or security.

Their goal is to have stakeholders have an “aha” moment when the value of IT work is crystal clear.

3. Reframe careless statements

Hunt for any statements that downplay the importance of critical work.

Anytime you hear “we can do it later” or “it’s not our job”, explain how stakeholders experience such.

This is not a call to take in new orders like a McDonald’s drive-thru staffer.

Even tech-unsavvy stakeholders deserve careful listening and responses.

Train engineers to respond thoughtfully to project discussions, even if they’ll backlog or decline tasks later with the PO.

4. Mini task forces

When a blocking issue arises during sprint planning and the team can’t answer it, create a mini-team to work through it in the background.

As the manager, assign to it engineers who are capable — but not entirely proactive — to power up their autonomy.

The approach teaches developers that complex problems don’t stop progress but get handled through focused effort.

5. Daily lead rotation

Giving team members the option to run meetings prepares them to step in when project management gets derailed.

Most of our senior developers can lead dailies and planning for the PMs.

Just in case.

If that foundation is in place, the manager should teach less experienced members to step in.

You want the team to understand the PM’s challenges through direct experience.

6. Multiple support pillars

You never want to depend on a single expert — like me, or a PM, or anyone else.

Most projects rely on a single person for deployments, integrations, or production fixes.

One person seems enough until, inevitably, something like the infrastructure or an API fail.

Think of the critical tasks within your project.

The idea is to prepare less experienced developers to take them on under the guidance of seniors.

To build such a foundation, a manager really can’t skip that paperwork time:

• rotate critical tasks among team members,

• insist on having key processes documented,

• don’t skip skill gap audits.

The transformation from a fragile, single-point-of-failure process into a robust, multi-pillar structure creates camaraderie that benefits everybody.

Next time

In Effective Delivery 11, Andrzej Wysoczański will perform surgery on processes in development that don’t really support feature delivery, which is what the business pays us for.

I hope I entertained you today!

Thanks for reading 🙏🏻

🟣 Substacks we read

🤯 Context switching. Endless meetings. Competing demands. Conflicts. AI disruption.

It’s no wonder so many managers feel overwhelmed.

That’s why thousands turn to Thriving in Engineering.

Written by 25+ year industry veteran Alex Ponomarev, every issue gives you tools to stay grounded, lead with confidence, and grow your career on your terms.

👉 Start with Alex’s guide on How to Master One-on-Ones — then subscribe to get new tactics and playbooks every week.

Thriving In Engineering

How To Master One-On-Ones

Have you ever had a friend you hung out with in a group, but the moment you were alone, you had nothing to talk about…

Read more

a year ago · 1 like · Alex Ponomarev

Published with a smirk by The Software House

Twarda 18, Warsaw, Poland

tsh.io →

It was created by our senior technologists who’ve seen how strategic team management raises delivery performance by 20-40%.

TL;DR

• Without standardization, teams waste weeks debating tools and building duplicate systems

• Standardize project setup templates first to eliminate repetitive configuration

• There are 8 areas IT managers can standardize

• Look for standards created by engineers that could help the entire team

• We cut project setup from 3 days to 30 minutes thanks to our boilerplates

Contents

1. Endless tool choices slow down teams

2. What to standardize (in order)

3. How to introduce standards

Hey! Adam here again.

Giving developers complete freedom to choose their tools doubles (or triples) delivery time.

This can manifest in many ways:

• Teams can waste weeks debating whether to use React, Vue, or Angular when they could be building features,

• Developer might insist on testing their favorite AI coding assistant instead of writing code,

• We once worked with a corporate client whose 20+ teams had to coordinate just to update a simple logo across their websites.

The difference in tools and tool know-how among developers is what’s causing the slowdown.

It’s time to bring back the monarchy to deal with this chaos! 😄

Today, you’ll learn what IT should standardize, and in which order, based on our own history.

Endless tool choices slow down teams

The wider your tool selection becomes, the lower your overall efficiency is:

• Each new gadget requires learning time,

• Developers lose work efficiency if they keep switching tools,

• Too many tools limit the feature team’s chance to master them.

So, if you narrow down the options, engineers should spend more time on delivering features.

That’s why standardization is good.

Our developers used to choose their favorite AI tool.

But the freedom to choose Copilot, Cursor, Windsurf, or some Devin created chaos.

We wasted time on explaining the differences between them.

We now have 2 approved options only.

GitHub Copilot or Cursor.

Each project uses just one of them.

Some managers falsely believe standardization means forcing one solution onto everyone.

Real standardization provides a spectrum of pre-vetted options and eliminates endless evaluation cycles.

At TSH, our teams build frontends in React + Next.js (internal/external) or Vue (only external per client’s request).

No Angular. It wasn’t a fit.

Most of our engineers maxed out AWS expertise for the same reason.

Unblock Delivery in 2-4 Weeks

Did you know? My engineers at TSH help organizations fix delivery blockers in 2 sprints max. Results are guaranteed.

Learn how they help

What to standardize (in order)

1. Project starter templates (week 1)

Your platform team or a senior full-stack developer should create these templates.

Companies create new features or services more frequently than they realize.

The manual setup of such burns precious time.

Our three starters (React Starter, Express Boilerplate, and Serverless Boilerplate) save us days of work on each commercial project.

They include CI/CD pipelines, a standardized log format, and authentication that works out of the box.

Find them on our GitHub!

2. Authentication (week 2-4)

Your architect or technical lead should standardize authentication patterns.

Authentication touches every application you’ll build.

We built components that use Azure AD once and apply them everywhere.

In the past, we coded a tailored user and authorization service for each app.

To get off the hamster wheel, we switched to Azure AD internally.

In commercial projects, we suggest Fusion Auth, Auth0, or Keycloak.

3. Design system (month 1-2)

Your frontend lead and UX designers should build the design system.

All internal applications at TSH use the same components.

We based our design system on ShadCN with our branding.

Instead of asking how a table should look, our engineers ask if we have that component and build for everyone if we don’t.

4. Data fetching (month 2-3)

Your backend architect should define data fetching standards.

Define exact specifications for how tables request data from backends.

Otherwise, developers will waste time working with different standards.

One engineer might use ?sort=name:asc, while another will prefer ?orderBy=name&direction=ascending.

We created a “data grid” standard.

It’s built into our design system and the backend boilerplates.

Every endpoint that serves table data follows the same query parameter structure, returns the same pagination metadata, and handles sorting and filtering identically.

5. CI/CD automation (month 3-4)

Your DevOps engineer or platform team should automate pipelines.

IT teams shouldn’t spend time on setting up CI/CD.

When we create a new project with our starter, it rolls out a preset for data and log collection.

It also includes configuration for GitHub actions, Gitlab CI, and Bitbucket Pipelines which cover:

• unit and integration tests

• E2E tests

• static code analysis

• security scanning

Your engineers should know that deployment always looks the same across all projects.

6. AI assistants (month 3-4)

An Engineering Manager or the CTO should evaluate and select AI coding tools.

We settled on Copilot or Cursor.

We track success through token usage.

Over the months, it went from near-zero to 45% for 220 of our engineers.

70% is our new goal.

7. Core technologies (month 4-5)

The CTO should define the approved technology stack with the architects.

Shrink the stack to see more developers who mastered it.

A choice limited to 1 per area is best for speeding up delivery.

Here’s how we did it at The Software House

Please note we need multiple choices to work on software projects across industries

• Frontend and backend

1 to 2 frameworks (like 1 for spa and 2 for ssr) and 1-2 languages depending on the use case.

We primarily use React/Next.js and PHP/node.

• Full-stack

Node and React.

• Databases

1 database per data type.

We use PostgreSQL for relational, MongoDB for documents, and Redis for caching.

• CMS

1 out of 3 options, depending on the media hosted and accessibility for editors.

We approved Storyblok, Payload, and Contentful.

• Authentication

Fusion Auth, Auth0, or Keycloak.

• AI and data engineering

Node/Python.

• Cloud

We use AWS in 90% of projects but also specialize in Azure and GPC.

How to introduce standards

If a feature team has to solve the same issue twice, mark it for standardization.

An architect can transform the feature team’s solution into a standardized package.

Then, the Team Lead / Engineering Manager can see if the new standard:

• is being discussed during dailies,

• is a part of the code seen during reviews,

• is reflected by any usage metrics connected to it,

• is used by new engineers in their first weeks (what we do).

And do watch out for engineers promoting an alternative solution that’s “more convenient”.

They might not get that you’re trying to save time.

Next time

Personal responsibility.

It would surely help engineers stick to the agreed standards!

EDN#10 will explain how managers can motivate team members to take ownership.

My friend Jakub Pawełek (our Delivery Manager) will take over.

Thank you for your time today 🙏🏻

🟣 Substacks we read

Ever feel like your hard work goes unnoticed?

You’re not alone. That’s why thousands of engineering leaders subscribe to Thriving in Engineering for practical guides that turn invisible effort into visible impact.

Written by 25+ year industry veteran Alex Ponomarev.

👉 Start with this piece:

Thriving In Engineering

From Invisible To Indispensable: An Engineering Manager’s Guide To Showing Impact

If a tree falls in a forest and no one is around to hear it, does it make a sound…

Read more

10 months ago · 1 like · Alex Ponomarev

Published with a smirk by The Software House

Twarda 18, Warsaw, Poland

tsh.io →

It was created by our senior technologists who’ve seen how strategic team management raises delivery performance by 20-40%.

TL;DR

• IT teams manipulate story points to look better without improving

• Some metrics encourage cheating rather than delivering value

• IT managers can encourage productivity by showing metrics as proof of success rather than failure

• The solution is to track four metrics proving efficiency: deployment frequency, production bugs, cycle time, and lead time.

Contents

1. Why team managers choose the wrong metrics

2. The 4 metrics that prove business value

3. How to refocus the team

Hello! It’s Adam again.

I’ve helped deliver over 160 IT projects.

And I continue to notice is that many IT managers track delivery using vanity metrics like:

• Story points

• Velocity

• Number of code lines written

• Number of commits

• Number of pull requests

They’re useful. But, most of the time, they only create the illusion of success.

I saw projects where teams delivered their sprints perfectly for months with stable velocity.

And yet, product updates kept being delayed..

As a CTO, I believe that only four metrics actually show if teams deliver business value:

• Deployment frequency

• Production bug count

• Cycle time

• Lead time

Why managers choose the wrong metrics

They’re simply stuck in a cycle of observing and fixing irrelevant metrics.

And the only thing that should matter is the business value that IT helped to produce.

1. Scrum encourages faking progress

Teams control what goes into sprints and how many story points each task costs, which means they can manipulate these numbers.

That’s also why every team estimates differently.

One team can say a CRUD operation takes 3 points while another says 8 points.

Quite often, when a team fails to deliver a sprint, it will first reduce the scope for the next one.

But its efficiency won’t improve.

2. Doing what everyone else does

I believe that most managers honestly try their best to measure efficiency.

It’s just that the metrics they choose don’t prove the team delivers business value.

Many managers believe that velocity will tell them what they need.

However, velocity depends on each team’s circumstances, making it difficult to compare the velocity of two different teams.

As a result, managers don’t have a benchmark against which to weigh their team’s performance.

The same goes for metrics that focus on individuals.

We had a client who connected a tool to GitHub that measured commits, lines of code, and pull request frequency.

Developers responded by making many small commits instead of writing pragmatic code.

The project quality dropped because everyone optimized for the metrics instead of creating value.

If you tell a team you want more pull requests, they’ll split one meaningful change into ten.

The metric improves, but the actual work doesn’t get better.

3. Metricphobia

Engineers tend to see metrics as weapons to be used against them rather than helpful tools.

They rarely hear which metrics their CTO is reviewing, or what impact such measured results can have on their future at the company.

Fear forces them to optimize for the vanity metrics I’ve mentioned.

The 4 metrics that prove business value

After years of working with clients across 8 industries, I’ve concluded that there are only 4 metrics that matter for measuring delivery efficiency.

These metrics meet 2 critical conditions:

• They prove if the feature team can deploy quality code quickly,

• The numbers can’t be easily gamed or manipulated.

Let’s review them.

1. Deployment frequency

This metric reveals the team’s capability to respond to problems.

If the team can’t deploy daily, a critical production bug might take too long to fix.

You can’t fake this metric as deployments either happen or they don’t.

2. Production bug count

When users say the UX is somehow broken, rarely can anyone argue with their experience.

Counting production bugs is critical since each of them can affect their experience.

The reduction in production bugs also proves the improvement in code quality.

3. Cycle time

This metric tracks the journey from when a developer starts a task until it reaches production.

If you want to expose the bottlenecks that block delivery, start observing it.

Soon, you’ll recognize where in the SDLC the team gets stuck most often.

We analyzed one feature team with a 20-day cycle time.

Development took only 3 days. Then, QA needed 2 weeks for testing.

We taught developers to test their code, and the cycle time dropped to 1 week.

4. Lead time

Lead time adds planning and refinement time to cycle time, measuring a task’s delivery from backlog entry to the release.

When stakeholders ask for new features under a dead-set deadline, lead time can reveal if the expectations are realistic based on the actual delivery history.

If the team’s lead time averages 50 days, promising any feature delivery in two weeks would be a guaranteed failure.

How to refocus the team

1. Start with transparency

Normalize working with engineers on the 4 metrics I’ve mentioned:

• Deployment frequency

• Production bug count

• Cycle time

• Lead time

The key is to show how their releases improve them.

For example, put the numbers on screen during your meetings and demonstrate how having developers test their own code reduces production bugs.

IT teams must see the same dashboards that managers use.

When the metrics are transparent, the discussion about them changes from defending against management to solving problems together.

2. Improve the metrics in the right order

Fix deployment frequency first.

Your ability to respond to emergencies depends on it.

Once the feature team deploys more often, it can focus on reducing production bugs.

After you improve deployment and quality, optimize for delivery speed by shortening the cycle and lead time.

This order prevents teams from shipping subpar code faster.

3. Measure the metrics using existing tools

Your CI/CD pipeline already shows deployment frequency automatically without extra tools.

Support tickets can count your production bugs clearly if you categorize them.

JIRA and similar platforms track cycle and lead time with the right config.

Other than that, a spreadsheet is enough to track these 4 numbers consistently.

4. Add a north star metric later

With the monitoring for the 4 efficiency metrics in place, you can improve delivery even more by adding a north star.

For example, Booking.com once used monthly reservations.

Technical improvements only mattered if they drove more reservations from users.

This single metric unified the entire organization around business value.

Other companies might pick another metric, such as user engagement or revenue per customer, instead.

Next time

Now that you know which metrics actually matter, let’s face the next bottleneck.

At least this one report suggests 75% of developers lose up to 15 hours weekly because they juggle around too many tools.

Without proper mentoring, IT teams might work with different databases or component libraries.

In the next issue, you’ll learn how we cut our project setup time by 80% through standardization.

Thanks for reading! ✌️

🟣 Substacks we read

If Effective Delivery helps you see the system, Thriving in Engineering helps you thrive inside it.

Join thousands of leaders and managers who subscribe for practical guides, frameworks, and stories that help you take control of your career.

Written by 25+ year industry veteran, Alex Ponomarev – it’s where tech leaders go to grow.

Thriving In Engineering

5 Lessons I’ve Learned As An Engineering Manager

It’s been many years since I stepped into my first engineering management role…

Read more

10 months ago · Alex Ponomarev

Published with a smirk by The Software House

Twarda 18, Warsaw, Poland

tsh.io →

It was created by our senior technologists who’ve seen how strategic team management raises delivery performance by 20-40%.

TL;DR

• Over-engineering and pointless meetings waste days of development time,

• Most developers fixate on technology and code quality instead on business value,

• Keep preaching about production metrics and task prioritization, and they’ll develop the value mindset,

• Keep an eye on % of reworked tasks, lead time to production, deployment frequency, and meeting efficiency.

Contents

1. Recognize & deal with team inefficiency

• The meeting trap

• Overengineering

• Overplanning

• Overdocumenting

• Code review wars

• Manual testing dependency

• Code perfectionism

2. Measuring success

What’s up?

Andrzej here with some chilli sauce for you 😀

Your IT team is probably wasting 40% of their time on tasks that contribute zero to the company’s bottom line.

Think about your feature team’s last sprint.

How much time did the team spend debating code formatting while actual architectural issues went unnoticed?

Have you ever heard of standups where 10 developers each drag on for 10 minutes?

I've seen teams spend weeks perfecting their service's DX while a client was waiting for that very service to be released.

IT managers must redirect all this wasted energy toward shipping things to production.

The stakeholders rarely value anything else, as they don’t dare to enter the backend.

Recognize and deal with team inefficiency

Your IT team is likely burning money on 1 or many of these 7 habits.

Each problem has clear warning signs you can spot today and solutions for tomorrow, most of which we’ve tested in commercial projects.

1. The meeting trap

The problem

Each hour spent in a meeting is one hour less for feature delivery.

I can’t make this simpler.

Please, defend yourself and the team, and don’t get roped in.

Developers really don’t need to be up-to-date on the project.

They just rarely speak up.

Some international clients might be protective of dailies.

Knowing that a development team shows up each workday signals accountability to them.

We once pleaded with a client to cut out dailies.

They cost them $4,000 per month.

They didn’t budge because "that's how Scrum works."

Solution

Replace marathon dailies with async Slack updates of just 2 sentences.

The PO or EM can still keep them responsible when the time calls for it.

Hold a 5-10 minute sync only for actual blockers with the engineers who work on it, and no one else.

Our average feature team at TSH saves around 8 hours weekly thanks to these rules.

2. Overengineering

The problem

When asked to explain their choice of technology, many developers will drift into a monologue about the specs.

Choosing a framework for its superior performance sounds smart.

But what’s smarter is to say that this framework can reduce checkout abandonment.

That’s what actually matters for the business!

The solution

Show developers how their work ticks off specific business metrics.

To feel that business value matters, they need to see that shipped features increase conversion or save money.

So, connect every technical decision to revenue impact.

Standardizing technology choice also saves hours — or weeks — of low-level debates.

3. Overplanning

The problem

IT teams also tend to spend hours on refinement to document every single edge case.

Sure, that ends with a perfect estimation in story points down to the decimals.

Then what happens? The CEO DMs asking for a "quick change" 😀

They’ve just lost 8 hours.

The solution

Managers can add a "definition of value" for each task to specify what business value it delivers.

When the team gets to refinement, the debate should center on understanding the user problem.

If priorities change frequently, planning should cover a maximum of one week.

Some ambiguity is better than wasting time on plans that become obsolete.

4. Overdocumenting

The problem

See if developers spend more time documenting than coding.

You're wasting money if you require documentation for every function and class.

Documentation that nobody reads is expensive fiction.

The solution

Code should document itself through clear naming and structure.

If developers can't understand code without a manual, the code needs rewriting.

Document only critical business logic and edge cases.

And if compliance needs everything on the record, let AI generate routine documentation.

Our team once inherited a 50,000-line code base.

The class names seemed random, like “Manager1” and “Helper2” everywhere.

The documentation had 200 pages. Yikes.

We had to rewrite the code with proper naming, which took 2 sprints.

Now, it needs no documentation at all.

5. Code review wars

The problem

Just in this one project, I witnessed developers fight over a 2-pixel code indentation in the comments section.

The business logic of the feature they were building had critical bugs that nobody caught.

Because of these battles, the project shipped three weeks late.

Management had no idea why the velocity dropped until we audited the review process.

The solution

Limit code reviews to a maximum of 2 hours.

Reviews must focus only on architecture, potential bugs, and business logic.

Ban all formatting discussions completely and use automated formatters instead.

You can also implement a double-check system where reviewers verify both code quality and feature completion.

Engineering managers should monitor code review times and step in when they exceed limits.

6. Manual testing dependency

The problem

Watch how long regression testing takes before each release.

The team’s wasting time if QA manually clicks through the same scenarios for days.

Each release delayed by manual testing could cost thousands in lost business opportunity.

Solution

Automate all main business flows and repetitive test scenarios:

• registration,

• login,

• purchases,

• critical paths.

Manual testing should focus on exploratory testing and new features.

When we automated 180 test scenarios, testing dropped from 5 days to 4 hours.

QA engineers then had actual time to pray for bugs instead of clicking around.

7. Code perfectionism

The problem

Prioritizing code refactoring while features are delayed is a red flag.

Similarly, optimizing products with minimal traffic is just dumb.

Perfecting code that already works is expensive procrastination.

The solution

Feature teams should always focus on shipping functional features first.

Business value beats technical elegance, and perfect code that never ships generates zero revenue.

Save refactoring for when the product has a revenue-positive number of users.

Ask your CPO or PO for the count.

Measuring success

Let’s be sure your gang won’t get hypnotized by story points or code coverage 😉

In the case of refocusing your engineers, use these 4 metrics.

• Lead time to production

We aim to deliver new features in less than a week.

If it takes longer, we comb through the grass looking for blockers.

• % of reworked tasks

Spending 30% of a sprint on bug fixes means the process is broken.

• Actual deployment frequency

Commits or pull requests don’t count.

If your IT deploys less than once per week, please contact The Software House.

We’ll help. Seriously.

The best IT teams deploy multiple times daily.

• Meeting efficiency ratio

Divide the hours in meetings by the number of decisions made.

Aim for 1 decision per 1 hour.

One client’s IT team needed 8 weeks to deploy.

Shocking. 5 departments had to approve the changes.

When the code reached production, the requirements changed.

Developers joked they were building for the past.

Next time

Adam will reveal why only four metrics actually matter for delivery in the next issue.

Lead time, cycle time, deployment frequency, and production bugs are the only numbers that matter.

I hope you enjoyed that bit of spice today 😋

Thanks for reading!

Published with a smirk by The Software House

Twarda 18, Warsaw, Poland

tsh.io →

It was created by our senior technologists who’ve seen how strategic team management raises delivery performance by 20-40%.

TL;DR

• Over-engineering and pointless meetings waste days of development time,

• Most developers fixate on technology and code quality instead on business value,

• Keep preaching about production metrics and task prioritization, and they’ll develop the value mindset

• Keep an eye on % of reworked tasks, lead time to production, deployment frequency, and meeting efficiency

• Success metrics must change based on the interaction mode

Contents

1. Why respecting interaction modes matters

2. The 3 interaction modes

• Collaboration

• X-as-a-Service

• Facilitating

3. Measuring success

Hey there! Adam reporting for duty.

Scrum actively discourages cooperation between IT teams.

Teams will also aim to avoid it.

But, inevitably, IT teams get co-dependent, and a PO or EM has to untangle them.

For instance, when an overbloated system needs to be split into modules, multiple teams with different pieces might start blocking each other.

Team Topologies defines 3 interaction modes with strict rules to combat cross-team dependencies.

You can match them to your business goals.

Collaboration mode works for fast delivery of features.

X-as-a-Service mode allows 1 squad to speed up the delivery of other teams.

Facilitating mode is for upskilling feature teams without building for them.

I’m 99% sure the team’s direct manager will set the interaction mode.

Still, I’ve seen too many managers making dubious decisions 😁

So, for the sake of your teams’ success, here’s how to use these interaction modes properly.

Why respecting interaction modes matters

I’ve seen IT teams drowning in requests too often.

And it looked like this:

• A stream-aligned team expected immediate API changes from a platform team that served 2 other teams,

• 3 different teams tried to collaborate closely with 1 DevOps team at the same time,

• An enabling team got stuck inside a feature team because people didn’t engage in learning enough.

Chaos! I don’t like to see it. Unless it’s an anime fight.

The three interaction modes force everyone to choose which task/request is a priority.

So, while teams don’t need a paper contract, knowing how a given interaction works prevents many delays.

Regardless of the mode, 2 golden rules apply:

1. No collaboration can last forever

There’s a start and end date. No discussion.

A feature team might want to snatch an architect and keep them as a new ace.

Unless you’re reorganizing a team, don’t let this slide.

2. A feature team can collaborate with just 1 feature team

It’s because both teams use up all of their cognitive capacity on the interaction.

Don’t mix in another stream-aligned team. Why?

One team needs 40 hours weekly to help another feature team reach maximum delivery speed.

Note that a support team interacting in the X-as-a-Service or Facilitating mode can actually collaborate with multiple feature teams.

The 3 interaction modes

Collaboration

It’s the most basic teamwork with transparent and near-immediate communication.

You discover solutions quickly thanks to shared dailies and no handoff delay.

Both teams will hope their bug tickets or data requests get solved on short notice.

Limitations

Team velocity drops when you have meetings with 10 to 14 people instead of just 5.

The information exchange is just overwhelming.

That’s also why collaborations aren’t really sustainable.

Expectations

Group members must be considerate, open to discussions, and available on notice.

Team members might get tense if they keep waiting for their peers to respond.

We worked as a feature team for a hotel booking platform.

We used to submit tickets for an API to the internal complex subsystem team.

Then, new orders came in with a tight deadline.

We convinced the PO to rent us 2 engineers from the in-house team.

Our interaction switched from X-as-a-Service to Collaboration to avoid delivery delays.

X-as-a-Service

90% of Scrum teams work in this mode.

It’s when a feature team takes ownership of a box of services developed for another frontline team.

They need to keep everything in that box running and aren’t concerned with other responsibilities.

Limitations

New service requests get queued and must be planned.

The tempo for delivering new capabilities is way slower.

Sometimes, the API you need now doesn't exist yet, or the service quality is subpar.

One client of ours works with 4 stream-aligned teams from our side.

Each team owns 1 application.

All of them rely on modules built by a stream-aligned team under the X-as-a-Service mode:

• payment modules,

• survey systems,

• and verification components.

The client’s feature teams use ready-made solutions to avoid weeks of grunt work.

Expectations

The service team should focus on the highest DX and UX of the components they produce.

If working with their API isn’t a pleasure, the collaboration won’t be effective.

The feature team might need some convincing to get back in the queue 😄

If the service team takes in an urgent request, it will set a bad precedent.

Facilitating

An enabling team helps feature teams become self-sufficient.

The teachers within it first master a domain like AI chatbots in an R&D project.

Then, they transfer their know-how to a feature team — but never build for them.

This eliminates the “bus factor”.

Limitations

You need your biggest geniuses in an enabling team.

Often, IT managers are unwilling to reassign them.

It's also the least used interaction mode, as most companies don't even know it exists.

Expectations

The teacher should remain present to hop into a task an engineer struggles with.

But the weight is on the members of the feature team as well.

They must have the will to learn, or the interaction won’t work out.

Your feature team might also try to rope in the enabler because of their 007 skills.

Collaboration doesn’t have to take place between complete teams only.

Often, you can create a commando squad of 1 for facilitation.

And platform team might just need 2 people

So, sometimes, you can “borrow” engineers from the feature team.

Measuring success

The real challenge isn't choosing a mode.

It's recognizing when your current mode isn't working.

Here’s what to look out for.

Collaboration metrics

• Cycle time and lead time improvements,

• Time to market for the specific feature,

• Speed of solution discovery.

If you're collaborating but delivery isn't faster, you're doing it wrong.

X-as-a-Service metrics

• User experience of consuming teams,

• API reliability and performance,

• Number of teams effectively served.

The focus is on being a good service provider and not on speed.

Facilitating metrics

• Number of dependencies eliminated,

• Time until the enabling team exits.

The team being taught must take ownership of a new activity.

Either they do or don’t.

Metrics won’t help much here.

Next time

You’ll hear about engineering obsessions that actually hurt your team's performance.

Like the honorary act of reaching 100% test coverage 😏

Thanks for reading today.

May you have patience for other humans 🙏

Published with a smirk by The Software House

Twarda 18, Warsaw, Poland

tsh.io →

It was created by our senior technologists who’ve seen how strategic team management raises delivery performance by 20-40%.

TL;DR

• A complicated subsystem team owns the most fragile parts of a platform or system,

• Its members must have deep domain knowledge and technical expertise,

• Payment systems, authorization modules, API integrations, or any other can’t-fail components should be handled by that team,

• One of our teams of this type eliminated coordination chaos across 20+ services by centralizing shared components

Contents

1. What defines a complicated subsystem team

2. Recognize when you need this team

3. Platform team vs complicated subsystem team

4. Use cases

5. Who belongs on this team

6. Measuring success

Hey there,

Andrzej here again 👋

Let me tell you about the most expensive mistake I've witnessed.

A client had ONE developer who understood their iOS payment integration.

The entire payment system was written in Objective-C.

In 2025, only a bunch of folks know it anymore.

That developer had a sudden accident and landed in the hospital.

IT couldn't push anything to production in that time and was left paralyzed.

Their CTO, a sharp man, was the second Objective-C expert on the inside.

And he totally missed this dependency.

If your product has a value flow that requires a niche skillset, you have a strong case for forming a complicated subsystem team to own it.

Let’s break this down.

What defines a complicated subsystem team

They own the critical or complex parts of a system that other teams depend on.

Imagine the people in the complicated subsystem team as surgeons.

They focus on cases where:

• every mistake has serious consequences for multiple teams

• deep domain knowledge and technical expertise must work together

• the solution is too complex for feature teams to build and maintain themselves.

The team must be able to create complete, production-ready solutions.

If they’re asked for an authorization module, they’ll return with something that can be installed immediately.

In our projects, the complicated subsystem team owned components related to:

• regulatory compliance,

• performance optimization,

• security updates,

• edge cases that would slow down any feature team.

So, how would your IT benefit from their grind?

Ideally, deep architecture work wouldn’t block all the feature teams.

In turn, delivery time should stabilize or improve.

Recognize when you need this team

I’ve been involved in dozens of projects where multiple feature teams had to do the same darn implementation separately.

An example?

Having 3 pet marketplaces in 3 countries serviced by 1 business unit.

Your organization might not be on that level.

But you might recognize these telltale signs that a complicated subsystem team should enter the field.

Your release roadmap keeps slipping

When people in the stream-aligned team get stuck on the same technical component, you have a systemic problem.

You could invest in upskilling…

But should your developers understand data parsing and processing, or is this an edge case that a support team could own?

We had 7 commercial projects in which we used 1 authorization solution.

In 5 of these projects, our teams kept having issues with it.

We formed a complicated subsystem team inside TSH to centralize and standardize the authorization process.

That eliminated the delays in our client work.

The "bus factor" is 1

You’ve heard the phrase, right?

One person gets hit by a bus, and the work halts.

You could tell the complicated subsystem team to own integrations, document them, and ensure they never depend on a single person again.

A simple code change requires massive coordination

I feel dizzy just remembering that one example I’ve witnessed.

A corporate client needed to swap the logo in the footer of 20-something websites they owned.

So, 20+ feature teams needed to be called in!

The same thing happened with phone numbers or menu updates.

Nobody centralized such shared components for years until we did.

Similar bug reports keep reappearing

An IT manager could see that bugs around areas like data processing or integrations keep reappearing for one or many teams.

Don’t let people solve the same problem independently.

It’s a clear case for a complicated subsystem team.

Platform team vs complicated subsystem team

These two team types often get mixed up.

Let's get this cleared out.

What platform teams do

They focus on technology R&D and building generic, standardized solutions everyone can use.

Examples

• A command-line tool for setting up new services,

• A platform for automating testing and QA,

• Modular templates for deploying server or cloud applications,

• Automated testing and QA platforms.

What complicated subsystem teams do

They build complete business solutions requiring industry-specific expertise that’s hard to get.

Examples

• Order processing and tracking subsystem,

• Customer account management and authentication,

• Infrastructure automation pipeline for multi-cloud deployments,

• Auto-scalable media streaming subsystem.

One of our seniors acted as a one-person complicated subsystem team.

A client had a shift scheduling system used by dozens of hospitals.

It was something like Excel in a browser.

Since hundreds of employees used it, the app lagged hard.

Our developer worked several sprints optimizing it.

He made the performance so reliable that all the feature teams didn’t have to worry about it.

Use cases

1. E-commerce payment systems

When multiple stream-aligned teams implement different payment functionalities in different places.

Some teams might use “pay now”, payment card processing, and a separate cart payment function at once.

In that case, one subsystem team can own all payment-related functionalities.

Payment issues would get centralized, saving everyone time on debugging and maintenance.

2. Banking system integrations

Imagine 3 teams building their own SEPA integrations, each debugging the same issues independently.

The complicated subsystem team could build microservices to handle external communications.

Then, feature teams would just send and receive data through APIs.

You’d also limit the scope of training on banking protocols.

3. Portals with shared components

Think of Adobe for a moment.

20 websites for 20 products, but each one is packed with text, media, and functions.

That’s a perfect case for having a team responsible for shared UI elements and business modules.

I can’t think of any other efficient way to cut an ecosystem update from days to hours.

One government subsidiary had 20+ portals with different Vue.js versions.

Suddenly, the end-of-life announcement dropped.

Think of the potential loss of vendors or compliance violations.

We formed an emergency complicated subsystem team.

They built shared components for all services in React that included:

• component libraries,

• project starters,

• table components with smart filters.

After the change, a new service with proper architecture could be created with 1 click.

Developers were also happy they didn’t have to wrestle with integrations anymore.

Who belongs on this team

You need your “jokers”.

The developers who are willing to master 2-3 new technologies yearly just for fun.

We often mix senior architects who decode system-wide impacts with domain experts who know the business inside out.

Building a banking system?

Well, your joker-engineer better be able to “breathe” banking.

Add performance specialists to the team when speed matters.

You’ll also need UX designers if they’re shared frontend components to build.

Also, I’ve seen managers try to form this team with juniors.

That’s a no-go, of course.

It’s for veterans only.

Measuring success

How do you know if your subsystem team is working?

• Cycle time should improve as teams stop getting blocked,

• There should be fewer bugs reported for shared modules when one team owns them,

• Roadmap delays should decrease when technical blockers are centralized,

• The manager should stop hearing about the same development issues repeatedly

Not seeing these improvements?

Your subsystem team might be solving the wrong problems.

Next time

We've covered all four team types from Team Topologies!

But it’s not vacation time yet.

You’ll need to figure out how all these team types can interact.

And there are 4 interaction modes designed in Team Topologies.

You’ll discover them in the next issue.

Thanks for reading! ✌️

Published with a smirk by The Software House

Twarda 18, Warsaw, Poland

tsh.io →