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

TL;DR

• Only 5% of developers become AI power users,

• AI skeptics are inherently unable to mimic the best AI users,

• Champions can show the goal, but the rest must reach it on their own,

• A shared AI framework is like a solid pair of boots for the journey.

Contents

1. Superusers will always be in the minority

2. Two ways of improving AI productivity

3. Tactics for raising the AI performance bar

Hey! Marek’s back.

One of our developers was going through so many tokens that we had to slow him down.

Another, a senior, refused to touch any AI tools for the longest time.

He was convinced he was fast enough without them.

Until a junior, armed with Copilot, matched his output, task for task.

If you are unsatisfied with your overall AI delivery gains and see things like this, you may be tempted to force everyone to work exactly like the top AI users.

It makes sense on paper, but doesn’t work in practice.

Superusers will always be in the minority

I’ve tried to copy one power user’s approach to working with AI for the rest of the team.

It didn’t work.

I’ve been implementing new tools in IT for 20 years, and I noticed that AI adoption follows the same normal (Gaussian) distribution as any other adoption process

There’s a minority of top performers and underachievers, and the rest fall in the middle.

At TSH, power users make up roughly 5% of the organization.

We’ve confirmed that, as we track how many tokens each developer uses and how much output they create with them.

The normal distribution is natural and will not flatten, no matter what you do.

Some will always use AI less earnestly and efficiently than others for various reasons:

• Their personality causes them to naturally resist any major change,

• Their satisfaction comes from the act of writing code itself, not from the result,

• They fear losing their expert edge when AI closes the gap between seniors & juniors,

• They lack the soft skills that AI-assisted development increasingly demands.

Two ways of improving AI productivity

When you pressure a developer to mimic the way a completely different person works, two things tend to happen.

They dig in further, or they leave.

Too many personal characteristics influence how developers interact with AI tools.

A better way is to focus on the middle of your Gaussian curve.

There are two broad team-level methods of doing that.

1. Removing AI delivery blockers

Your delivery processes may be limiting all of your developers’ AI performance:

• Product owners cannot generate tasks fast enough for developers to code,

• Delivery pipelines are not built for the pace AI can enable,

• Client acceptance procedures create handoffs that eat up the time savings.

The review of our first 100% AI-driven project addresses these blockers.

Guaranteed results →

2. Raising the AI performance bar

I’m going to focus on the second method, as it is a direct countermeasure to the fruitless attempt to copy the top AI user’s individual style.

It calls for:

• encouraging everyone to get inspired by the top performers’ results voluntarily,

• identifying certain standards of AI development that everyone should follow.

The second is about finding a minimum of standards that everyone can get behind without feeling forced to work in a way that is uncharacteristic for them.

Aside from following these rules, they are free to code, prompt, and work as they like.

That approach ensures lower turnover and higher satisfaction.

Tactics for raising the AI performance bar

Here’s how you can raise your team’s AI capability.

1. Involve your AI top performers

You do not have to pressure anyone to copy exactly how they work.

A better way is to have the top users show the AI skeptics all the possibilities.

Do a pair programming session:

1. The champion shows what is possible while the skeptic watches,

2. The skeptic tries while the champion observes and provides advice,

3. The skeptic develops their own method that incorporates some of the champion’s tips.

When the skeptic improves by their own initiative, they may become an AI advocate themselves.

One former skeptic gave a lightning talk about his conversion.

That talk resonated far more with the team than any power user showcase.

People could see themselves in his story.

2. Prove that AI works

Whether through power users or leadership, demonstrating AI’s effectiveness to skeptics is worth the effort.

I remember when we proved to some developers that the codebase in one project was not too complex for AI to handle.

On one project, the team was convinced AI could not understand their legacy system.

We asked them to skip the code and have AI generate documentation instead.

They read it and went quiet. The structure, the logic, the edge cases. All of it was there.

3. Start with the best models, then optimize

To drive your point about AI’s potential, give developers access to the most capable models from the start.

A poor first experience on a cheap model convinces a skeptic that the tools do not work.

On one client project, the team lost trust in AI due to inconsistent results.

When I asked which model they were using, it was the cheapest available.

We switched, and the complaints stopped.

4. Create feedback loops

Diesel engines improved by systematically addressing every reported problem.

AI tools work the same way, but only if the feedback actually reaches the people maintaining them.

Run monthly sessions where developers share what works and what needs fixing in the tools.

A complaint is not a feedback loop. The session must produce a specific issue to address.

For us, the sessions often produce feedback regarding our own AI framework, copilot-collections.

Those found valid by the framework team are implemented in the next version.

5. Give leaders real experience first

We have had cases where we asked a manager to promote AI adoption, even though they were skeptical.

When a team lead does not believe the tools work, the team quickly notices.

Leaders do not need to be power users, but they need to have used the tools enough to believe in them.

If they don’t, they should pair-program with top performers as described above.

6. Build shared frameworks that raise the floor

The highest-leverage change is tooling that makes good practices the default.

It should still be flexible enough to let developers feel they can put a personal spin on the outcome.

At TSH, we built copilot-collections with this in mind.

It is an end-to-end AI product development framework that provides every developer with a basic common workflow.

7. Involve skeptics in building the tools

An organization we learned from invited every developer to create their own agents and contribute to their shared toolkit.

It’s less likely to be skeptical about something you helped create.

At TSH, we run a more centralized model due to the sheer scale of our organization, but we still ask developers to suggest improvements and flag what does not work.

8. Accept the holdouts

After all the enablement, some developers will still not come around.

Don’t push them.

Give them tasks that require less AI-assisted delivery, or move them to areas where manual skill still dominates.

What works instead is time.

When everyone around them works faster and delivers more, the holdout tends to reconsider on their own terms.

That is what raising the bar means in practice.

Next time

In the next issue, Jakub Pleszewski will debut to explain how AI is changing the way software projects are estimated.

He will walk you through which aspects of estimation can be automated and which require human intervention.

Until next time 👋

More AI — more problems

Help us pay the bill for bitcoin mining

Share

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 code generation can now run without developer input,

• Losing focus during generation leads to poor-quality software,

• You should not scold individuals, but change processes to help them focus,

• Making smaller tasks and removing bottlenecks helps a lot.

Contents

1. The hidden cost of code generation

2. Things to do during code generation

3. How to keep developers focused

Hello. This is Andrzej.

What do your developers do after they write a long prompt and hit that generate button?

When your developers think a break is the right move, that is bad enough.

It is worse if you agree with them.

What your team does during AI code generation shapes your software’s delivery time and quality.

The hidden cost of code generation

Before AI, developers already had gaps when their code compiled or ran tests.

These breaks rarely took more than 5 minutes.

Without an AI helper to simulate thinking, developers relied on their own judgment to verify the code.

Today, a developer can write a long prompt, hit generate, and mentally check out for 10, 15, or 30 minutes.

The problem is that generation is the easiest part, and stepping away at that point puts the quality of the delivery at risk.

The truth is that AI has made code a commodity.

What matters is not coding, but knowing why you build something, how it fits the system, and what the AI got wrong.

The real cost is not the 15 to 30 minutes of generation time, but the hours or weeks it may take to undo the problems that a subpar, unverified solution creates.

One developer generated a table intended to show each user’s number of booked appointments.

When he added 5 appointments to a user and checked the result, the column showed a single dash in each cell instead of the appointment count.

The AI had seen a dash in the design file and reproduced it without questioning whether it made any sense as a value.

Things to do during code generation

Staying alert during AI code generation allows the developer to have a better command of the code and product through the following activities:

I’m sure you can think of even more things to add to the list.

But the challenge is not coming up with a list of productive activities for a developer.

It’s in reorganizing your workflows so that you don’t need to stand over the developer’s shoulder to ensure they actually do it.

How to keep developers focused

Even if you cloned yourself and had each clone supervise every developer, enforcing good habits would not work.

Practicing a lot of them involves active thinking rather than opening specific directories or browser tabs.

Unless you also have an idea on how to get into their brain, I suggest a different approach.

Design a system where staying engaged is the natural default.

1. Break tasks into smaller pieces

Smaller tasks generate faster, which shortens waiting periods.

The developer can plan the next step while the current one continues to generate.

Code review on small tasks is also faster.

At TSH, I prefer code reviews completed no later than the next day, with 2 fixed daily sessions.

A team on one of our projects used to run hour-long prompts and do other unrelated things while waiting.

The output often came back wrong and had to be reworked from scratch.

They switched to shorter, checkpointed prompts and started catching errors in minutes instead of hours.

2. Group tasks by functional proximity

When a developer finishes one small task, and the next one is related to it in terms of functionality, the context switch is minimal.

Both tasks share the same domain, mental model, and codebase area.

If a developer writes the logic for an “apply” button that sends a discount code, the next task should be adding the discount to the order summary breakdown.

Multitasking on unrelated tasks looks productive, but burns concentration.

3. Ask the right questions

You’re not helping your developer stay focused when you ask questions like “Is it ready yet?” or “What’s the progress?”

Instead, ask targeted questions.

• How does the solution fit into the broader architecture?

• What edge cases have you considered?

• Are you sure AI understood the context well?

Those questions are targeted enough to keep the developer on task without falling into micromanagement.

4. Keep a maintenance backlog

Some tasks don’t require deep thought from the developer.

That’s why, to keep a developer alert, it’s good when there’s always something useful to do.

One of our clients keeps a standing backlog of non-urgent tasks ready for whenever developers finish sprint tasks early.

These include bug fixes, technical debt, and documentation-related responsibilities, all ready for a developer to pick up and fill a gap.

These can cause some context switching, but they are better than nothing.

5. Align your business pace with AI delivery speed

Running out of tasks has a more elegant solution than a standing backlog.

With AI, developers can sometimes code so fast that task generation and code review can’t keep up.

When developers know that new tasks are not coming, they feel less urgency and zone out.

You need to use AI to speed up business analysis and code review, removing bottlenecks caused by coding speed.

We wrote one issue about that.

6. Train developers on AI collaboration

Developers who understand how AI makes decisions pay more attention during generation.

AI often chooses the path of least resistance, resulting in suboptimal solutions that don’t scale well.

Pair programming with your top AI users or external consultants can teach your developers how to spot these patterns.

Next time

Marek Gajda, our COO, will explore why some developers never become productive with AI, no matter what.

Is there still hope for them, or should you consider parting ways?

That’s it for today.

More AI — more problems

Help us pay the bill for bitcoin mining

Share

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

• Architecture is your real security layer,

• Grant models only the access they need,

• Treat every external input as a potential threat,

• Permission checks belong in the code.

Contents

1. Less AI — fewer problems

2. Validate input and output

3. Guard every tool and operation

Hey! Aleksander here.

Most IT teams I talk to spend a lot of time on prompts.

Prompts do matter, and they shape how the model works.

But when those same IT teams start using prompts to enforce security rules, I get nervous.

Writing “do not do this” in a prompt gives you no real guarantee the model will comply.

A longer context window, a conflicting instruction, or a misread edge case can cause it to skip what seemed obvious.

Security cannot rest on what AI should not do.

It must rest on what the system will not let it do.

Less AI — fewer problems

Despite all the hype around AI, I hold a clear position.

The less unnecessary AI in an application, the better.

If a problem can be reasonably solved without it, that is the right call.

You spare yourself unclear edge cases and extra costs.

And you avoid the surprises that come with introducing a nondeterministic element into the system.

When AI does belong, it works best on unstructured data, such as documents, messages, text, and natural language.

Beyond choosing where to use AI, you also need to decide what it can touch.

The model should not have access to everything by default.

Before implementation, define which resources, files, data, and operations the model needs to do its job.

Give it only those.

Broad access “just in case” sounds harmless, but a wider access scope means a wider error surface.

Guaranteed results →

Validate input and output

Any information entering the prompt, conversation, or model context from outside the system is potentially risky.

User messages are not the only risk.

Document content, a webpage fragment, a task description, and any other text the model receives for processing all counts.

Before that information reaches the main process, check whether the system should process it.

This matters most in chat systems, where the interaction volume is high and users have a lot of freedom in what they submit.

Prompt injection is a broad topic, and many tools exist to detect these risks.

The key principle is simple.

Do not treat external input as a trusted instruction for the system.

Apply the same scrutiny to what the model returns.

Before a response reaches the user or feeds further into the system, check for hallucinations and topic drift.

Check that the model has stayed within the expected tone, language, and application rules.

The stakes are highest when AI generates documents, summaries, or recommendations that decisions will depend on.

🇵🇱 Z Polski? Wpadnij na mój własny Substack i sprawdź jak rozkminiam inne strategiczne decyzje projektowe.

Guard every tool and operation

Agentic AI systems give the model a set of tools it can select and run depending on the operation.

Two things need attention.

First, which tools a user can see and run should depend on that user’s role, permissions, and tier in the application.

Not every user should have the same toolset available.

Second, each tool must run its own permission check before executing any operation.

That check belongs in the code.

Even if the model calls the tool, the code must be able to return an error saying this user cannot run this operation.

For critical operations, do not let the model decide on its own to execute them.

Treat AI as the component that prepares intermediate data and leaves final execution to the system.

The system then validates that data and maps it to the actual operation.

Working with a client on a summary tool, I hit this problem.

Instead of letting the model build a database query, I asked it to produce a JSON config describing what needed to happen.

The system then used that JSON to build the actual query.

That way the application’s own safeguards stayed in the loop and could reject unauthorized operations.

My position on direct database access for AI is straightforward.

Avoid it.

The model can generate a query it should not, or misinterpret what the user intended.

When direct database access is unavoidable, four rules apply.

• Read-only access only, no writes or deletes,

• In multi-tenant systems, restrict the data scope to the current client,

• Run an additional review pass on any SQL the model generates,

• Validate query results before they travel further through the system.

Cost monitoring belongs in this plan too.

Track not only implementation costs but the ongoing cost of every interaction.

Without per-user limits and real-time monitoring, one broken scenario can generate costs far beyond anything you planned.

An LLM Gateway between your application and the model handles rate limiting, cost tracking, and usage control from day one.

AI is not just another feature in the app.

Deploying it means thinking about security, access, limits, and control layers from day one.

It is closer to giving a user access to your internal tools than to adding another endpoint.

Build the system so AI cannot cause real harm when it misinterprets an instruction.

Design it to hold firm when the model tries to run an operation it should not run.

Prompts can help the model work correctly.

Architecture limits the consequences when it does not.

Next time

Andrzej Wysoczanski will look at the idle time that appears when engineers wait for AI-generated code to compile.

He will share concrete approaches for turning that window into productive work.

Back in 2 weeks 🤚

Would a friend of yours enjoy reading such stories?

Share Effective Delivery (effectivedelivery.io)

Olek recommends

Help us pay the bill for bitcoin mining

Share

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 generates tons of code, leading to review issues,

• A human-AI hybrid approach to reviewing works well,

• If AI misses a bug, refine the process instead of abandoning it,

• 100% AI reviews will become common in the future.

Contents

1. The problem with AI code

2. AI and humans can review together

3. The future of code reviews

Hey! Adam here.

Code generation is now lightning-fast, and human reviewers can’t keep up.

And yet, many companies insist that humans are essential to the review process.

If that were true, AI-driven development is inherently flawed.

After all, what’s the use of generating code fast if it’s stuck in the review anyway?

The problem with AI code

Let’s put aside whether a human is a necessary element of a code review for a moment.

The problem with reviews in AI-driven projects is the sheer volume of code.

When a developer runs 5 agents in parallel, the queue of PRs grows fast.

While the code is being generated, the developer may step away to get a cup of coffee or play a game of paddleball.

But reviewing every single one of these PRs may require a human’s attention, depending on how the review process is set up.

AI shifts the ratio of code written to code reviewed, and the review side cannot keep pace.

The result is that either the review takes longer, or it gets less thorough.

AI and humans can review together

Let’s assume that we don’t want to eliminate a human from the code review process entirely.

The most practical solution is to add a routing step to the CI/CD pipeline.

A simple version of it could work as follows:

1. After a developer opens a pull request, an AI agent reviews the change and provides a go/no-go signal.

2. A go means the developer merges without waiting for a human.

3. A no-go means a human reviewer steps in, sees what the AI flagged, and decides.

That way, developers skip the queue on low-risk changes, and human attention goes where it is needed.

Guaranteed results →

AI reviews require clear rules

There are at least two things you need to make sure of for that process to work well.

1) You need to have clear standards for a review.

For example, a button color change may carry a different risk than a change to a payment flow.

For the button, an AI approval is fine.

For a payment flow, I want a human responsible for the outcome.

If your IT team reviews code the same way every time, you have a standard you can automate.

2) You need to write down all the rules.

If there are clear, repetitive patterns in your review process, you turn them into rules and make them accessible to AI agents, they can, in principle, handle routing and reviewing.

Our own AI framework, copilot-collections, is an example of that.

Copilot-collections offers a 4-step development process, with a separate AI agent responsible for each step.

One agent implements a feature and a second reviews it against acceptance criteria.

If something does not pass, the agent sends feedback to another agent, which fixes the issue automatically if possible

The future of code reviews

We now know that a human and an AI can collaborate on code reviews.

But let’s now remove the assumption that a human is necessary in the review process at all.

Many people hold the view that code has not truly been reviewed unless a human has looked at it.

I believe that it is a cultural, rather than a technical, issue and stems from AI’s novelty.

Just like a self-driving car having an accident causes an uproar, we hold AI to a stricter standard, even when AI makes fewer errors overall.

Security vulnerabilities exist in codebases today that passed human review without being flagged.

Assigning a human to code reviews does not guarantee quality.

Most IT teams have accepted that AI-written code can reach production.

Accepting that AI-reviewed code can also be well-reviewed code is the next step, and it will happen the same way it always does, gradually, as teams see it work.

When an AI review problem occurs, it is a reason to improve the process rather than abandon it.

Next time

Waiting for AI to generate code may be a good time for a developer to take a breather.

But if these “AI breaks” are frequent, your developers could consider doing something productive during that time instead.

My friend Andrzej will share his best ideas for developers to use during that time in the next episode.

Now, that is something worth waiting for!

Check out one of our most popular pieces!

Help us pay the bill for bitcoin mining

Share

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

• New technology introduces risk you rarely need,

• Conference inspiration without critical thinking does real damage,

• Your framework choice must meet functional and non-functional requirements,

• “Boring” technology wins because it is predictable and maintainable.

Contents

1. Resume-driven development

2. Context matters

3. Why you shouldn’t switch

4. Put reliability first

Hey!

Aleksander here.

Every week, a new framework appears.

And you still have a React frontend, an Express backend, and a PostgreSQL database.

Very often, that is a good decision.

Choosing technology for a project is not simple.

On one hand, you need to ship a working application quickly.

On the other hand, you will maintain it for a long time afterward.

And rewriting a system almost always turns out to be too expensive.

In this issue, I want to show why “boring” technologies win, where resume-driven development begins, and how to make technology decisions you will not regret six months after going live.

Resume-driven development

You know the drill.

You go to a conference, you hear about an interesting technology such as GraphQL or DDD, and you come back inspired.

There is nothing wrong with that on its own.

The problem starts when someone comes back and wants to turn the project upside down right away, just to use a new approach, without deeper analysis and without checking whether it actually fits.

It often ends in disappointment.

The fact that something worked for a speaker does not mean it will work in a different context.

Presentations show solutions under specific conditions, with a specific team, problem, and set of constraints.

This pattern is fairly common, and it can cause damage when IT teams start building systems not based on real requirements, but on the desire to try a new tool.

That is where it is easy to enter the territory of resume-driven development.

Resume-driven development means making technology decisions not because the project needs them, but because they look good on a resume.

Context matters

When designing systems, IT teams often look at how large companies do it.

IT teams copy microservices, multiple technologies, specialized databases, and custom solutions for specific problems.

The problem is that most applications do not operate at that scale.

In practice, 90% of applications do not need separate technologies for every use case.

That level of complexity translates to higher development and maintenance costs, not real value for the user.

Large companies such as Netflix, Uber, and Bolt did not start with elaborate architectures.

They started with simple monoliths and straightforward applications.

The goal was to test the idea, acquire users, and understand the problem.

Only later, when real traffic, data, and specific bottlenecks appeared, did they choose more specialized tools.

They did not make that shift before the scale demanded it.

Why you shouldn’t switch

Inspiration from large companies or conference novelties is not inherently wrong.

The problem starts when IT teams apply such inspiration without asking whether a given technology actually fits the project, the team, and the real business needs.

Technology should not be evaluated through the lens of whether it is “cool.”

The starting point should be concrete criteria that help you make an informed decision.

Old beats new

When you have worked with a given technology for a long time, you know its flaws, limitations, and problems.

Paradoxically, those known flaws are often the reason why sticking with proven technology is the right call.

Proven technologies are stable, predictable, and you know how to configure and maintain them in production.

New solutions carry the risk of surprises.

Immature tooling, gaps in the ecosystem, and problems that only surface in a real production environment are all things you cannot predict in advance.

🇵🇱 Z Polski? Wpadnij na mój własny Substack i sprawdź jak rozkminiam inne strategiczne decyzje projektowe.

The right competencies

You might be a Vue fan, but if your team has experience mostly in React, proposing to rewrite the application in Vue will probably not go as smoothly as it seems.

The team will need time to learn the new framework, and then more time to reach the same level of efficiency as before.

The person who proposes a new technology takes on responsibility for onboarding the rest of the team, quality control, and problem-solving.

It is doable, but it is neither fast nor free.

Maintenance overhead

Every technology, whether a framework, library, or platform, carries an operational overhead that must be factored in before making a decision.

Deploying a simple container and connecting it to a database is a different thing from maintaining a Kubernetes cluster in production.

At conferences, you often hear that Kubernetes provides high availability, scalability, and system resilience.

That is true, but those benefits have a price.

Functional requirements first

Every technology must meet the functional and non-functional requirements of the application.

If the project requires good SEO, you will not reach for plain React.

If specific security standards or regulations apply, those narrow the possible choice of tools.

For me, requirements are always the starting point, and they naturally limit the range of technology decisions.

Guaranteed results →

Put reliability first

Not every project requires the same approach to technology.

Business-critical applications should rely on proven, mature technologies.

Choosing innovative solutions means taking on responsibility for their stability, maintenance, and any problems in production.

Smaller supporting applications give more room for experimentation.

They are good candidates for testing new tools in a limited scope and seeing whether they deliver in practice.

Private projects can serve as a playground where you learn new technologies without any business risk.

Technology decisions must always be made in the context of the specific application and its future maintenance.

Do not let FOMO or resume-driven development drive them.

“Boring” technology does not win because it is perfect.

It wins because it is predictable and maintainable.

Next time

Adam Polak believes AI-generated code is becoming the biggest delivery blocker ever.

It’s dirt-cheap and faulty by design.

He’ll share his tactics for staying safe around it.

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

• 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

• As a CTO overseeing 220+ technical professionals, I see that 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 →