• Your manager proposed a new process completely disconnected from reality.

• A product manager brought a long list of questionable features while the project was collapsing under technical debt.

• A teammate opened a pull request with a quality bar far below what you consider acceptable.

Have you ever stayed silent because you didn’t know how to disagree without starting a conflict? Or maybe you tried to speak up, but the conversation somehow turned into a disaster?

Most of us have such experience.

We often avoid conflict because silence feels safer. But it’s hard to love your work when you’re surrounded by decisions you don’t respect. Great products rarely emerge when nobody challenges the status quo. Teams stop growing when nobody raises the bar.

Even more, unspoken issues rarely disappear. They repeat. Initially small pinch eventually becomes a painful crunch.

Conflict is always an opportunity for improvement. The ability to raise concerns without fear, disagree constructively, and prevent poor decisions is an essential ingredient of a healthy, growing environment.

But if conflict can be a good thing, why do we avoid it?

Because conflict is only productive until it becomes personal, and that happens surprisingly often.

Why Do Work Discussions Become Personal Conflicts?

Have you ever noticed how quickly discussions about seemingly ordinary work topics can become emotional? Why does this happen?

Human psychology is complicated and full of nuance, but one explanation appears surprisingly often: many of us associate our work with our identity.

Most engineers don’t just work for eight hours and leave the problem behind when they close their laptop. We think about problems while walking. We solve bugs in the shower. We wake up with solutions at 3 a.m.

That happens because we care. The feeling of “I am a good engineer, I am a professional” becomes part of our identity. Being someone who can solve complex problems with practical, elegant solutions matters to us. And we often treat the outcomes of our work as evidence of our competence, something that reinforces that identity.

And you know what? This is not unique to engineers. Designers, product managers, founders - many people feel the same connection to their work. When we care deeply about what we do, that becomes a part of our definition of who we are.

Now imagine someone criticizing other's work. To the person receiving the criticism, it often doesn't feel like criticism of the work. Sometimes it feels like attack to their identity.

This happens especially often under stress. The amygdala, the part of the brain responsible for threat detection, becomes more active under stress, while the prefrontal cortex, which supports reasoning and self-control, has less influence. The amygdala is fast, but not very accurate: it is designed to notice possible threats quickly, even at the cost of false alarms. Evolutionarily, this is a successful survival strategy: it was safer to react to a threat that was not there than to miss one that was.

Because of that, people under stress may perceive attacks even when none were intended. They stop listening and start defending, counterattacking, or withdrawing - anything except having a useful conversation. This is simply how our brain is wired.

There are two important conclusions from this:

1. If you criticize someone’s work, they may become defensive instead of hearing you, and you'll not succeed.

2. Even if you do not intend criticism, people may still hear it that way.

So, let’s look at a few techniques that can help you express disagreement clearly, but without threatening people’s identity.

Four Techniques for Productive Disagreement

A Dream Behind the Complaint

This is the simplest technique, and surprisingly often, it’s enough to change the direction of a conversation.

Whenever you notice that something is bad, you usually also have an idea of what “good” would look like. So instead of describing how bad things are, describe the better version you want to see.

Instead of:

This process makes no sense.

Try:

I’d love a process where engineers can deploy routine changes the same day, unless there’s a clear reason for extra approval by 3 persons.

Instead of:

This pull request is impossible to review.

Try:

I’d find this much easier to review if we split it into a few smaller changes.

This works because you’re no longer judging the person’s work. You’re describing a desired outcome. The conversation becomes less about blame and more about improvement. It also becomes much easier to act on because they're more specific.

Anticipate the Fundamental Attribution Error

Fundamental Attribution Error is a cognitive bias that became widely known thanks to Daniel Kahneman's book "Thinking, fast and slow".

It is a mental shortcut where we overemphasize a person’s character traits when explaining others behavior. At the same time, when we make mistakes ourselves, we usually blame the situation instead of our own personality.

When my colleague is late, it’s because they're disorganized and don’t respect our time. When I’m late, it’s because traffic was bad.

We often do this unconsciously. And we naturally assume that other people judge our personal qualities. We may overestimate how likely that is, but it still creates stress. This is simply how our brain works.

One of the easiest ways to reduce defensiveness is to explicitly acknowledge the circumstances around the situation.

I know you’re working on this PR under a tight deadline.

I see you created this PR late in the evening.

The requirements for this task seem unusually ambiguous.

I know we don’t have many good examples of tests in our codebase at the moment.

By acknowledging situational factors you remove an unspoken fear: the fear that you’re secretly judging. It turns the conversation into a partnership.

Express Your Need. Clearly

A surprisingly large number of disagreements come from unmet needs. The problem is that we often hide those needs behind criticism. Instead of explaining what is difficult for us, we explain what is wrong with someone else.

For example, there are many reasons why you might be unhappy with a pull request. Is it too large to review? Did someone send it late in the evening and ask for urgent feedback? Are you concerned about code quality? Do you disagree with the task requirements themselves?

These are very different problems, and they require different actions. And it is worth explaining why you struggle clearly.

When we express our need, people are willing to help, much more often than we can expect. So, try shifting the sentiment from "You’re doing it wrong" to "I’m struggling because..."

Instead of

Why are you sending a PR at 10 p.m. and expecting everyone else to drop what they’re doing for your poor planning?

try

This is critical functionality, and I’m too tired to review it well tonight. I could do it tomorrow with a fresh mind.

Instead of

It is poorly designed

try:

I’m worried this hidden behavior will increase support load for us

If the situation is tense and you’re struggling, let others see that. There’s nothing wrong with it.

This way, you’re not attacking their identity, you’re asking for help which creates a very different kind of conversation. The focus moves away from judging another person and toward solving a specific problem you experience.

It also creates empathy. People generally enjoy helping each other, but they can only help when you express what you need. So, do it clearly.

Be Part of the Solution, Not a Passive Observer

Nothing kills a discussion faster than criticism without action.

When expressing disagreement, propose specific actions, even small ones, instead of passively judging or arguing for a perfect but unreachable state.

Please make this a separate PR so it’s easier to review.

or

I’m okay with this workaround, but let’s identify the long-term solution before merging.

Even if you don't know the exact solution, you can still offer partnership:

Let’s spend 30 minutes together to untangle that. I'm available at 4 p.m.

I often think about disagreements as a ball of thread. As long as the thread keeps unrolling, the conversation can continue. Statements like these cut the thread:

I don't like it.

I disagree.

This is wrong.

They end the conversation instead of advancing it. A better alternative is:

I disagree with X, but I see Y and Z as possible alternatives. What do you think?

The thread continues, and that's where progress happens.

It works because you offer a concrete next step, which can move the conversation out of endless debate or analysis paralysis.

It also creates a partnership dynamic. You become collaborators solving a problem together, instead of one person evaluating the other.

When You Feel Emotionally Involved

Everything above helps reduce the chance that the other person becomes emotional. But what to do when someone involved emotionally is you?

The short answer: pause.

First, take a breake and remind yourself of positive intentions: you are on the same side, and the person in front of you is not your enemy.

That may sound obvious, but in the heat of an argument, we often start treating colleagues as if they are actively sabotaging us. In reality, they are usually trying to solve the same problem, but from a different perspective. The article I linked above was a game changer for me when I first read it 10 years ago, and I still reread it regularly.

Second, make sure you have enough emotional capacity to carry the conversation through to the end. If you haven’t slept properly for the last few days, your chances of having a constructive conversation are close to zero.

Wait at least until morning.

This advice works surprisingly well outside work too: don’t discuss difficult topics in the evening. In the evening our self-control is depleted, and it becomes harder to regulate ourselves. Casinos open in the evening not by accident. Children’s parties happen in the morning for a reason too.

Third trick that helps enormously is writing before speaking. Draft the message, prepare the opening. Writing forces your brain to slow down and apply a more thoughtful filter. And a good opening often sets the tone for the entire conversation.

Is It Possible to Never Have Personal Conflict?

No.

These techniques cover 90% of situations, but there is still the remaining 10%. Personal conflict will still happen from time to time.

That’s why one of the most important skills is learning how to repair relationships after conflict.

Don’t pretend the conflict never happened. Talk about the moment where communication broke down and take responsibility for your behavior - acknowledge the impact it had on the other person, even if that was not intentional. Then explain what you will do differently next time.

The best way I know to repair a relationship at work is to solve the original problem together. For example, instead of continuing to exchange pull request comments until everyone is exhausted, finish the pull request in a pair-coding session.

It is impossible to get rid of conflicts completely, but it is possible to recover from them. Often that makes the relationship even stronger.

Summary

Conflict itself is useful. The problem starts when conflict becomes personal.

And that can happen surprisingly easily. Many of us connect our work with our identity. So when someone criticizes our work, we may hear it as criticism of who we are, especially when we’re under pressure.

The goal is not to avoid disagreement. The goal is to express it clearly, but without damaging others:

• describe the better outcome you want, not just what is wrong

• acknowledge the context before criticizing

• express your actual need clearly

• propose a concrete next step instead of passively judging

When you feel emotionally involved, pause. Remind yourself that others have positive intentions. Have some rest before starting a difficult conversation. Write your thoughts down before speaking.

You won’t avoid personal conflict completely. Nobody can. But you can reduce how often it happens, and learn to repair the relationship when it does. That could turn difficult conversations into moments of trust, clarity, and better work.

Useful resources

• Trust in Positive Intentions

• How To Criticize Coworkers

• Constraints on giving feedback

• Nobody Pushed Back: Why Engineers Stay Silent Until It's Too Late

• Ted Talk: The Single Most Important Parenting Strategy

• Inside Standford's "Touchy feely class"

Years of mergers and shifting requirements had left the project chaotic, with key domain experts long gone. But over time, my team and I turned things around — today, we’re considered the most effective team in the company. That transformation took a couple of years and taught us valuable lessons.

In my previous article, I shared how we helped overloaded individuals. But it wasn’t just a few people — the whole team was under pressure. This piece focuses on how we addressed that team-wide overload.

When I joined, teammates often said, “Stakeholders won’t let us recover the project, they just keep piling on requests.” But were the stakeholders the villains? I don’t think so. The real issue was that stakeholders didn’t know the team’s real capacity. And to be fair, how could they if the team didn’t either?

Once we started examining our own work, we uncovered a lot to improve. It started by identifying the gap between expectations and what the team could actually deliver.

What Was the Team Expected to Deliver?

When I joined, there wasn’t much clarity around how work was structured. That’s not unusual. When you’re constantly putting out fires, it’s hard to find time to zoom out and look at the bigger picture.

So I spent my first three months observing everyday work and what stakeholders typically expected from us. Here’s how work was supposed to be divided among our six engineers:

• Epics: large, high-priority initiatives. They always consist of multiple tasks, and come with deadlines. My team was expected to work on three Epics at once.

• Standards: smaller feature requests without natural deadlines. However, the team followed a Kanban SLA practice that tasks shouldn't stay in the backlog for more than six weeks. This rule distracted the team, leading them to focus on low-value work just to meet the SLA.

• Support included customer issues that frontline support couldn’t solve and ad hoc requests from other teams using our system. The expectation here was a quick turnaround — basically, “fix it now”.

• Intangible work was another class of service borrowed from Kanban. For us, it meant technical debt. One engineer was supposed to handle it, but only if there were no Support tickets waiting which, of course, happened rarely.

The first clear problem with this setup was that every task came with some kind of commitment — a deadline, an SLA, or the urgency of a support ticket. In practice, this meant each engineer was always tied up. So when someone got stuck or an incident happened (which was often), the only option was to drop some commitment. We had no flexibility to absorb surprises, and since surprises were routine, we routinely failed to deliver on our promises. To put it plainly, our initial setup made failing commitments almost inevitable.

The second issue was siloed work. Each engineer had their own tasks and mostly worked alone, which meant limited knowledge sharing. Since we were always under pressure, tasks were assigned to those who already had the necessary expertise, leading to even more knowledge silos over time. This, in turn, led to multitasking because it was rare for the most knowledgeable person to be available when an urgent request came up.

The third problem was that all of this was considered the baseline. So whenever someone took a vacation, got sick, or left the team, something would fall behind. If you do the math — six engineers, each with four weeks of vacation — almost half the year, someone is unavailable. Yet, the expectations never changed.

These are classic signs of an overutilized team, and that was considered a minimal expectation for us.

But the reality was even worse because those four categories didn't cover everything.

Facing Reality: The Unseen Workload

While clarifying expectations, I also tracked what was actually happening in the team's daily work. It didn't take long for the numbers to reveal their own story: on average, we dealt with five to six urgent tasks per month, whether it was a production incident or a last-minute business request.

For example, our Kafka mirroring cluster went down three times during my first two weeks on the project. Each time, the team hurried to get it running again. The better solution was to move a couple of services to the other data center and get rid of this mirroring cluster, but that required more effort. When you're always in emergency mode, there's no time for strategic fixes.

According to the data I gathered, such tasks took an average of four days to resolve, meaning that the team was dealing with at least one unexpected, urgent issue at any given time. So, the reality was that we had an ongoing stream of unseen work that wasn't considered in the expectations, yet it took up a significant amount of our time and energy.

Aligning Expectations with Reality

Given the lack of trust from stakeholders, I knew we couldn’t overhaul everything overnight. We needed to take small, deliberate steps.

Step 1: Minimizing Distractions

The first priority was to carve out space for the team to focus by reducing the constant stream of expedites.

I shared my findings with the VP of Engineering using the same images you saw above. To address the issue, I proposed reducing the number of simultaneous Epics from three to two and introducing a weekly rotating Quarterback role within the team.

The Quarterback would handle anything that threatened the team’s progress, whether it was an urgent incident, a teammate stuck on a task, or an unexpected blocker. Essentially, the Quarterback’s role was to manage chaos so the rest of the team could remain focused.

In the short term, this should help us to shield the team from distractions. In the long term, the goal was to get ahead of recurring problems and fix them at the root so we’d stop getting pulled into emergency mode so often.

We also started tracking where the Quarterback spent their time each week.

At first, the quarterback role was fully occupied with the “red swimlane” — urgent issues and constant firefighting. But instead of just applying quick fixes, we started tackling the root causes behind these incidents. That shift to a systemic approach paid off. We reduced the number of monthly incidents from six to one (and, as of 2025, we have one incident per quarter). In addition, we’re now resolving incidents much faster, thanks to having a dedicated teammate to solve them and to improve our most painful troubleshooting tools.

Eventually, the Quarterback role began shifting toward less urgent "yellow swimlane" tasks, indicating we were ready for the next step.

Step 2: Shifting from Risk Reaction to Risk Prevention

The next thing to tackle was our approach to technical debt.

Stakeholders often complained that the team spent too much time on “technical stuff” instead of delivering visible progress. At the same time, engineers were frustrated that they couldn’t spend time on technical debt at all.

As usual, the truth was somewhere in the middle.

Officially, one engineer was supposed to handle technical debt (tasks labeled as “Intangible”), but only if there were no Support tickets in the queue. According to the data, we averaged four Support tickets at any given time. As a result, technical debt was never addressed in a planned manner.

This wasn't new. A couple of years earlier, leadership decided to delay addressing the technical debt "until things got better." Of course, things didn't improve; they got worse. The team still dealt with tech debt, but only when it blew up as production issues — another instance of unmet expectations, leaving stakeholders frustrated. So, we actually were spending time on technical issues, but only reactively, when they’d already caused damage.

One example really highlighted this issue: we had a backlog item to upgrade CentOS 6, which reached its end-of-life in November 2020. We knew about this issue, but never had time to prioritize it. When November 30 arrived, CentOS 6 was removed from official repositories, and our delivery pipelines broke.

We got the pipelines working again with a custom image. But here was the bigger issue: running production on an unsupported OS lowered our company’s security rating, hurting its reputation and raising insurance costs.

So we had to drop everything and urgently upgrade the OS. Except it wasn’t just a simple upgrade — some of our customers were still using outdated SSL/TLS protocols that newer OS versions didn’t support. That meant we had to coordinate changes with customers before proceeding. It turned into a months-long distraction, all because we hadn’t addressed a well-known risk in a planned way.

This made one thing painfully clear: the so-called “intangible” work had very tangible consequences.

I went back to our VP of Engineering with a new proposal. We would remove the unclear "Intangible" label and stop using the overused term "technical debt." Instead, we would divide technical work into two clear categories: risk reaction and risk prevention. We would allocate planned capacity to focus on risk prevention, encouraging the Quarterback to spend as much time on this area as possible.

The goal was simple: tackle potential issues before they became emergencies.

Step 3: Empowering the Team with Autonomy

Once we reduced the number of emergencies, the team finally had room to breathe. We could meet our commitments more consistently and, just as importantly, start rebuilding trust with stakeholders.

The Quarterback began spending more and more time in the risk prevention swimlane. They addressed long-standing technical issues, resolved major security problems, improved diagnostics and support tools, and fixed weak areas in our delivery pipeline. These changes made the entire team more productive and helped rebuild stakeholders' trust even more.

With that gained trust, we made three more important changes:

1. We got rid of the six-week SLA for Standard tasks. It had been pushing the team toward overcommitment and inflexible planning. After a lot of discussion, we agreed this practice was doing more harm than good.

2. We stopped requiring approval for each individual technical task. At this point, we were consistently delivering what stakeholders expected, which gave us enough credibility to take more ownership. We no longer had to negotiate each technical task. Instead, we began focusing on what was most valuable at the moment, with an agreed-upon capacity of one teammate, rather than sticking to decisions made weeks earlier.

3. We shifted from the initial “push” approach — assigning tasks to the team based on a monthly plan — to a “pull” model, where each teammate picks up the next task only after completing their current one. If someone is blocked, they don't take on a new task. Instead, the team focuses on resolving the blocker. If the blocker will be present for a long time and can't be addressed immediately, a teammate first offers help to others with their tasks before taking on a new one.

By now, most of the technical risks had been addressed, which meant we could shift more energy toward planned development work.

And since this was a 25-year-old system that had been under constant pressure for years, there was no shortage of messy problems that needed fixing. One example: our end-to-end tests were running on a version of Chrome that was 40 versions behind the current one. Obviously, those tests couldn’t reliably tell us if the app worked for real users.

Now we've got both the time and the autonomy to clean up that kind of stuff, too.

Step 4: Achieving More with Less

The changes we’d made so far helped a lot. We improved our technical foundation, reduced emergencies, and started delivering more predictably. But some deeper issues remained.

First, everyone was still working solo. That limited knowledge sharing and made the team fragile — if someone was out sick or on vacation, progress stalled. Also, some of our Epics could’ve moved faster if we had worked together, but we weren’t set up for that.

Second, we had already dealt with the easy parts of technical debt. What remained were large, high-impact projects, like moving all secrets (passwords, tokens, certificates) to the Vault to secure our delivery chain and improve our audit readiness. But these efforts required months of focused, coordinated work — something our current setup just wasn’t built to support.

So I went back to the VP of Engineering and pitched a new approach:

1. Fewer activities but approached as teams

We collapsed our work into two swimlanes: Epics and Standards, not based on priority, but on how the work should be done.

• Epics are major initiatives that require focus, flexibility, and collaboration. Success means delivering on time and with high quality. So, we assigned four of our six engineers to this swimlane and let them self-organize. They could choose to work as one team of four or split into two teams of two. They could decide whether to pair-program or mob-program to share knowledge or work on tasks in parallel. We kept a hard limit of two concurrent Epics to prevent overstretching.

• Standards became a catch-all for smaller work: feature requests, minor tech tasks, and support tickets. Two engineers handled this swimlane and had full autonomy to decide how to balance the workload. If Support tickets were piling up, they could team up to get through them faster. If things were quiet, they could knock out Standard tasks.

2. "Standards" is an adjustable swimlane

If the Standards swimlane wasn’t busy, we had the flexibility to temporarily move one or both engineers to help with a certain Epic. This gave us the agility to handle high-impact work in the best possible way.

3. Rotations for growth and resilience

To avoid burnout and build shared knowledge, we introduced regular rotation between the two swimlanes. Everyone got the chance to work on both Epics and Standards swimlanes. This encouraged skill growth, avoided silos, and promoted natural knowledge sharing through pair or even mob programming.

The biggest benefit of these three changes was that they gave us the autonomy to decide how to do our work. Of course, autonomy requires a certain level of team maturity. But the thoughtful steps we’d taken over the past two years helped us get there. Each team member now understands the value of our work, how we make and keep commitments, and how we handle risk.

Another significant change was that we started doing fewer tasks, but with more focus. We reduced our commitments from six (sometimes more) to just four. This allowed us to complete tasks faster and with higher quality. It also made the team more resilient: if someone working on an Epic went on vacation, progress didn’t stop. Planning time off became easier and less stressful.

This is how “doing more with less” looks in action: fewer things in progress, but more things getting done.

And it worked.

We started consistently meeting — and often exceeding — business expectations. The team gained a reputation across the company as one of the most effective, reliable, and forward-thinking. We became a go-to example of how to build mature development practices: integrating security into development, adopting continuous delivery, and systematically eliminating whole classes of risk.

What Was the Impact of These Changes?

I believe the most meaningful measure of success is the change in sentiment. Upper management no longer labels us a “stuck” team—in fact, we’re now often cited as the most efficient team in the company. Burnout has noticeably declined, and team members report feeling far more satisfied with their work. They now see their contributions as impactful and meaningful.

However, I intended to give you some numbers.

On average, we now complete tasks five times faster than before. Reducing multitasking, enabling deep focus, sharing knowledge, improving the codebase, and investing in tooling helped us speed up every phase of delivery: development, code review, testing, and deployment.

Even more importantly, our predictability has improved. The standard deviation of task completion time has dropped 4×, thanks to reduced uncertainty in the codebase and tooling, more pairing, and fewer interruptions. Today, when we commit to something, we do it with much more confidence.

Perhaps the most illustrative metric is our average pull request lead time — the time from the first commit to merging into the main branch. It captures the full story: the dip in performance after the company split and subsequent acquisition, the impact of losing key engineers, and then the steady improvement after we reshaped how we work. When I joined, PR lead time averaged 17 days. Today, it’s just 1 day:

Of course, that single metric doesn’t capture everything, but it shows how much is possible when you stop overwhelming a team and give them the space to focus.

It’s difficult — if not impossible — to isolate the impact of any single change. The improvements we’ve seen are the result of many adjustments compounding over time. For example, integrating security into development and achieving measurable delivery improvements with DORA metrics (among others, I haven’t written about yet) significantly boosted our effectiveness, and none of it would’ve been possible without the process changes described in this article.

Are you curious about the other changes we introduced to make this happen? That’s exactly why I created this blog. I’ll be sharing more stories and lessons — stay tuned.

Conclusion

When a team struggles to meet expectations, the reflex is to tighten control. But in reality, the opposite is often needed: teams need some slack to absorb risks.

What I hope this story shows is that meaningful change doesn’t have to start big. You can shift a team out of firefighting and rebuild trust through small, deliberate steps: aligning expectations, proactively resolving tech debt, letting the team shape how they work, and doing fewer things better.

Much of what worked for us reflects core Kanban practices: start with what you have, limit work in progress, make process policies explicit, and let the team self-manage and focus on outcomes.

Is our current approach perfect? Not at all. Swimlane rotations rarely line up cleanly — people finish work at different times, and deep-focus tasks don’t pause just because it’s rotation day. Moreover, Support and Standard tracks often drift apart again, with one person handling all the Support requests while another works through Standard tasks alone.

But that’s okay — this isn’t a fixed configuration. Continuous improvement is about learning, adapting, and making the system a little better. Repeatedly.

Life is so beautiful,

Fedor

Years of mergers, acquisitions, and losing domain experts had left the project in disarray. Outdated tools made even the simplest tasks difficult. Yet, despite these challenges, my team and I turned things around. The project runs smoothly today, and we take pride in what we’ve built. But getting here was no easy feat — it was a journey full of lessons about managing burnout, technical debt, and teamwork.

One of my first challenges was dealing with the crushing workload on certain team members. Many were stuck in "firefighting" mode, unable to focus on structured, strategic work. This not only burned them out but also held the entire project back.

In this article, I'll explain how we helped one overwhelmed team member regain control. I also wrote another piece about how to help the whole team.

The Signs of Trouble

My first day started with a flood of emails about the same issue: our logging system was down, triggering nonstop alerts that annoyed the team and a dozen other managers.

What happened? Our DevOps engineer (let’s call him Andrew) was updating our logging tool, Graylog, when the Kafka mirroring cluster on production went down. Andrew, the only person who knew how to fix it, had to drop everything to resolve the issue, leaving the Graylog update unfinished and still firing alerts.

It didn’t take long to see that Andrew was under immense pressure. During our first one-on-one, he admitted, "I’m feeling a bit worn out." He constantly bounced between crises, with no time to address root causes or make lasting improvements.

Worse, we had a bus factor of one for Andrew. If one day he decided to leave (and the chances of that were higher because he was overwhelmed), the whole project would be in serious trouble.

This was a typical antipattern often described as “DevOps is a culture, not the role”. Relying too heavily on one person is a way to a fragile, unsustainable system.

Hiring another DevOps engineer seemed simple, but we had strict staffing limits. But even if we could, it wouldn’t fix the core issue: Development and Operations were working in silos despite being part of the same team.

Diagnosing a Root Cause: a Pile of Unfinished Work

So, why was Andrew so overwhelmed?

The root issue was a mountain of unfinished work—quick fixes and half-implemented solutions that had built up over the years. These incomplete tasks required constant maintenance, catching Andrew in a vicious cycle of firefighting.

Take the abovementioned Kafka mirroring cluster, for example. It crashed three times in my first two weeks. After the third crash, I reached out to Andrew to find a systemic solution, and 15 minutes later, we realized we could move two services to the primary data center, making this Kafka mirror unnecessary. Years ago, this mirror was introduced as a temporary solution to migrate some services to the primary data center for GDPR compliance. But like many temporary solutions, it stuck around indefinitely.

Another example was our messy production setup. We had four different deployment methods: RPM installations on VMs, Docker, self-managed Kubernetes, and AWS. Only Andrew knew how to manage all of them. Over the years, these tools were introduced but never fully adopted, creating a "Lava Flow" anti-pattern — an incomplete, messy setup that hardened into permanent. We simplified deployments by standardizing on Docker and cutting 70% of our Jenkins code, reducing cognitive load and allowing the whole team to become proficient in our delivery pipelines.

And, of course, there were plenty of undocumented tasks that only Andrew knew how to do.

The pattern was clear: unfinished work was the cause and the effect of Andrew’s overload.

The Solution: Identifying and Distributing Workload

The solution was obvious:

• Identify all unfinished tasks.

• Spread responsibilities across the team to reduce reliance on a single person.

• Free up Andrew’s time for high-value work instead of constant interruptions.

• Ensure the team can operate smoothly even when Andrew is away.

This is easier said than done, starting from identifying unfinished work. When someone is overwhelmed, it’s hard to see the whole picture and identify long-term solutions. Andrew could only recall the latest fires he had put out, a common experience for those stuck in reactive mode.

I turned to David Allen’s Getting Things Done method and its “trigger list” technique. This method helps to offload mental clutter and identify everything demanding attention. For us, it was a way to detect unfinished work.

I customized my "triggers list" for Andrew, adding all our services and tools.

Then, I asked Andrew to:

1. Set aside a few hours without distractions—no phone, no messaging apps.

2. Go through a list of triggers and jot down any tasks that come to mind. Don’t try to organize them — aim for quantity, not quality. Refining comes later.

3. When your mind feels clear, take a break. Avoid doing mental work—go for a walk or have a meal instead. More tasks will likely come to mind, and they should be written down, too.

Andrew was on board with the idea since he felt overwhelmed by work and personal matters. We agreed he’d go through this exercise and share the work-related part with me to tackle them together.

But unsurprisingly, he struggled to find the time. So, I suggested he take two days off solely to focus on creating the list. The next day, he returned with a stack of notes we finally turned into 200 tasks!

Sharing the Work and Spreading Knowledge

We broke that massive list into manageable categories and identified an approach for each:

1. Teach: Many tasks, like restoring Kafka, weren’t difficult — just undocumented. We started informal "morning coffee" sessions where we broke production and Andrew guided us through hands-on exercises. We recorded each session, creating a reference library for the future.

2. Document: we had a massive lack of documentation about our day-to-day maintenance routines. Instead of forcing full documentation upfront, we wrote instructions as tasks arose. Then, another teammate would follow the steps from the doc and refine it, ensuring clarity and usability.

3. Do: We divided tasks into three categories: those only Andrew could do, those requiring his guidance, and those the team could handle independently. Interestingly, some of Andrew’s routine tasks were exciting challenges for others. We assigned tasks based on each person’s interests to contribute meaningfully and learn.

The Results

Over the next few months, we redistributed Andrew’s workload. For example, I took over our delivery pipelines, reworking them and improving delivery speed and stability with DORA metrics.

Our litmus test was whether Andrew could spend a vacation without our emergency calls.

It took nearly a year, but we got there. The project became significantly more stable, and the team gained the confidence to handle long-standing issues independently. We fully embraced Continuous Integration and Delivery (CI/CD), transitioned to Infrastructure as Code (IaC), and improved our observability tools. DevOps was no longer just Andrew’s responsibility—it became embedded in our team culture.

The impact was not just surface-level adjustments. We delivered real, measurable results:

• Incident frequency dropped: We used to have 1–2 urgent incidents per week. Within a year, this was reduced to one every 2–3 months, allowing us to focus on long-term goals and improving our ability to meet expectations, restoring the business’s trust in our commitments.

• Proactive risk mitigation: Instead of scrambling to fix last-minute critical vulnerabilities, we managed risks ahead of time, preventing disruptions before they occurred.

• Risk Reaction vs. Prevention: Previously, we mainly dealt with problems only after they blew up, like updating an outdated OS only after the vendor removed the image. A year later, we were handling most risks proactively, preventing disruptions before they could occur.

Conclusion

Burnout and over-reliance on a single person are signs of an unhealthy work environment, not individual failings. The reason is often piles of unfinished work that repeatedly disrupt the team.

If some of your teammates are in a similar situation, take action:

• Identify and prioritize unfinished tasks.

• Distribute responsibilities across the team.

• Foster a culture of knowledge sharing.

• Ensure the team can function smoothly, even in the absence of key members.

This transformation won’t happen overnight, but each step makes a difference. Aim for the ultimate sign of success: you and your team can take a well-earned break without emergency calls.

Life is a lot better when the fires stop burning.

Fedor

However, my team and I managed to turn things around, and adopting DORA metrics was pivotal in this journey.

In this article, I’ll share how these metrics helped us detect bottlenecks, redesign our tools, and streamline processes, transforming a project once thought unsalvageable into a well-oiled machine.

What Are DORA Metrics?

Before diving into the details of our story, let's quickly review DORA metrics and why they matter.

The DevOps Research and Assessment (DORA) is a multi-year research that examines thousands of companies to explore the connection between software development practices and business outcomes.

The book Accelerate: The Science of Lean Software and DevOps explains this research in-depth and is a must-read for anyone looking to improve software development efficiency.

DORA's research identified a set of engineering, process, and cultural capabilities closely tied to company performance. Also, it introduced four key metrics to measure software delivery performance, which fall into two categories:

Throughput Metrics:

• Deployment Frequency: How often the team deploys code to production.

• Lead Time for Changes: The time it takes for a commit to reach production.

Stability Metrics:

• Change Failure Rate: The percentage of deployments that result in a failure.

• Time to Restore Service: How long it takes to recover from a failure.

According to the DORA research, these metrics reveal underlying issues like poor design, excessive manual work, or bureaucratic obstacles. They provide insights into the overall efficiency of the development process.

💡A vital note on metrics

The idea of measuring and improving development efficiency isn’t new.

However, traditional metrics like lines of code or test coverage have often become the subject of jokes rather than true success indicators. For example, linking compensation to lines of code leads to bloated, inefficient software. Similarly, setting test coverage as a target can result in excess tests without meaningful assertions.

DORA metrics are a breath of fresh air because they focus on team performance rather than individual output. They balance speed and stability, helping us avoid the common trap of over-prioritizing one at the expense of the other. Furthermore, DORA metrics show real work, making them more valuable than velocity-based metrics like story points or the number of tickets, which can be "improved" without changing the actual work.

That said, like any metrics, they can be misused, leading to unintended and harmful outcomes. I highly recommend reading the Accelerate book and watching Bryan Finster's talk "How to Misuse DORA DevOps Metrics" before introducing any efficiency metrics to your team.

Assessing the State of Our Project

When we first collected DORA metrics from our CI system and visualized them in Grafana, the results were alarming:

• Deployment Frequency: every two days

• Lead Time for Changes: 10 days

• Change Failure Rate: 25%

• Time to Restore Service: 29 hours

While deployment frequency had already improved from the monthly "big-bang" releases when we were optimizing our team processes, the other metrics painted a grim picture. A 25% failure rate and a 29-hour recovery time meant that one in four releases would break the system and take a full day and night to fix.

Imagine being a developer in this situation. You want to make a slight improvement, but you know it will take ten days for the change to reach production, and there’s a 1 in 4 chance that the release will fail. If it does, you'll spend an entire day and night fixing it, all while juggling your current work. Would you take the risk of introducing additional changes to the code in such conditions? Probably not. Even without knowing the exact numbers, experience tells you it’s better not to.

Even worse, this fear of change compounds over time. Flaws pile up, the codebase becomes harder to understand, and the fear of breaking things escalates. This is a vicious cycle.

But just as vicious cycles exist, so do virtuous ones. The more often we make changes, the easier they become. This gradually reduces our fear of change and increases our confidence and ability to improve in smaller and smaller steps with lower and lower risk.

Our 25-year-old project had its share of architectural and code quality issues, but DORA metrics revealed another big problem: our delivery pipelines were causing significant overhead and risk with every change. We decided to focus on optimizing the delivery pipeline first, making it easier to clean up the project later.

So, we focused on improving the delivery pipeline and making it easier to troubleshoot deployment failures.

Uncovering the Major Delivery Bottleneck

Our project was structured as a monolith with 13 services, which inherited a delivery pipeline from the original monolith years ago.

Here is how the code went through git branches and CI pipelines:

One red flag in our pipeline was the repetition of identical steps. Moreover, our end-to-end (e2e) tests that we ran repeatedly were a known bottleneck.

These tests were comprehensive, running 3,500 tests across four production-like clusters and verifying all the critical business cases. However, they had serious drawbacks:

• Limited hardware: Only one e2e-test pipeline could run at a time.

• Unstable execution times: Tests could take anywhere from 30 to 90 minutes.

• Flakiness: Failure rates averaged 25%, spiking to 50% during bad periods.

• Debugging difficulties: There was no way to run or debug tests locally, and according to the metrics we gathered, fixing a flaky test could take up to five days.

Our e2e-tests were a constant source of frustration. Developers frequently said, "I finished my changes yesterday, but I’m still waiting for the e2e-tests to pass."

To see how such tests can turn even simple changes into arduous toil, let’s imagine that we need to quickly fix the infamous Log4j critical vulnerability across our 14 services. Our steps will be the following:

1. Create 14 pull requests and get 14 “green” e2e-test runs. The up to 50% failure rate of tests combined with 14 services meant up to 28 test runs. Considering the ability to make only one test run at a time, this alone took up to four workdays.

2. Repeat the same process for the develop and main branches: this added another eight days of testing and waiting.

3. Release all 14 services: this took another half day.

Finally, it takes a grueling 12 workdays to update a dependency and fix a critical vulnerability! Something as simple became an overwhelming ordeal.

Streamlining Delivery

So, we identified two root problems to address: the instability and complexity of our delivery pipeline and the challenges with our e2e tests.

For the delivery pipeline, we removed all the redundant steps, such as creating dedicated release branches, and automated the rest, like preparing release notes and notifying stakeholders.

Our commitment to pipeline optimization has gone so far that we have built a Slack bot integrated with the Jenkins pipeline to manage releases (I’ve detailed this in a separate article). This bot automates everything from changelog collection to health checks and rollbacks. Additionally, it allowed us to deploy the entire system at once when needed.

Regarding the e2e-tests, we did the following:

• Reducing unnecessary e2e-tests demand: Instead of running e2e-tests on each service individually, we implemented a pipeline that runs tests and generates release artifacts for all 14 services at once. In cases like updating dependency across all services it reduces test demand by up to 14 times. Additionally, we eliminated the develop branch that was practically redundant to us. That helped us avoid running e2e-tests twice on identical code and reduced unnecessary merges.

• Making tests optional: initially, e2e-tests were running automatically on each branch. We decided to run e2e-tests for feature branches only if the developer explicitly specified that. After three months of monitoring, we confirmed that the stability of the main branch was unaffected by this change. Unit tests, which we began prioritizing, proved sufficient for verifying changes before merging.

• Optimizing test execution: We stabilized test execution time from 30-90 minutes to the stable 25 minutes.

Let’s look at how we would handle the same Log4j vulnerability after applying all these changes:

1. Create 14 pull requests and get 14 successful builds: Without the need for e2e-tests on each branch, it takes about 1 hour in total.

2. Merge the 14 pull requests into the main branch and get one “green” e2e-tests: While we've optimized the test execution time, we still face occasional stability issues. As a result, this step may take up to two e2e-test runs, resulting in 30-60 minutes.

3. Deploying all 14 services: now, with the Slack bot and the ability to deploy all services in a row, this step takes 30 minutes.

Thus, what once took 12 long workdays now only takes a couple of hours. Isn’t that great?

We implemented all described changes throughout December 2022-January 2023. The graphs with 4 DORA-metrics below show clearly that starting from February 2023, the situation has changed dramatically:

These changes opened the door to continuous improvement and we aimed to make our pipeline even more efficient. Here's what we did:

• Implemented health checks and alerts: We added additional checks to detect issues immediately after releases. We scrutinized every deployment failure over the next three months and steadily made our process more robust.

• Enhanced e2e-test debugging: we invested in the e2e-tests debugging experience and reduced the average time to fix flaky tests from five days to one day.

• Optimized e2e-test triggers: We discovered that most of our e2e-test runs generated release artifacts for the monolith. Even when a push to a microservice repository triggered e2e-tests, another push to the monolith often existed, triggering the tests again. So, we limited the e2e-test triggers to just two scenarios: pushes to the monolith’s main branch and twice-daily scheduled runs. This simple adjustment additionally reduced demand for e2e-tests without compromising our throughput or overall efficiency.

To tell the full story, these improvements significantly boosted our throughput, but this increased the frequency of changes and caused e2e-tests to remain a bottleneck. Because of hardware limitations, we could only run one e2e-test at a time, and the average idle time before starting e2e-tests was about 30 minutes.

So, we reused the hardware set to be retired and built a second test environment, which reduced the wait time for running e2e-tests from 30 minutes to 0 minutes. This persuaded leadership to acquire more hardware, enabling us to run two e2e-test pipelines simultaneously and remove the bottleneck completely.

Another point worth mentioning is that we haven’t been able to eliminate flaky tests — they still crop up occasionally. Our long-term strategy is to reduce reliance on e2e-tests by gradually replacing them with more efficient integration and unit tests.

The outcome

To illustrate the transformation, here’s a comparison between our initial metrics and where we stand now:

• Deployment Frequency: Once every two days (before) → multiple times a day (now)

• Lead Time for Changes: 10 days (before) → 14 hours (now)

• Change Failure Rate: 25% (before) → 0.7% (now)

• Time to Restore Service: 29 hours (before) → 26 minutes (now)

Beyond the improvement in DORA metrics, I’d like to share my personal observations on how these changes impacted the team and the project as a whole:

• Team morale has drastically improved. Without the constant overhead and firefighting, we can make steady improvements while meeting business demands. We still have technical debt from the past 25 years to tackle, but now we have the confidence and momentum to resolve these issues over time.

• Releases no longer require all-hand coordination. Previously, we had to schedule releases for specific times, and the whole team had to gather together. The necessity to release in the evening, on Friday, or before the holiday was highly stressful. Now, any team member can initiate a release at any convenient time.

• Development throughput also has increased:

  • The time from the first commit on a feature branch to merging into the main branch has dropped from 17 days to less than a day — a clear indicator of improved code maintainability and tool quality.

  • Task completion has gone from an average of 15 days to 5 days.

• Emergency fixes have all but disappeared. Previously, we handled about 6 "expedited" monthly tasks to fix critical issues. These disruptions are so rare and swiftly managed now that we no longer log them in Jira.

• We’ve achieved things that seemed impossible before. In just five months, we resolved 97% of the security debt accumulated over the previous 25 years. During that period, we deployed over 400 releases without disturbing a single user. This level of throughput and stability was unimaginable before we applied DORA.

Conclusion

The right approach and tools can revive even the most challenging project. I hope this story inspires you to take on technical debt in your projects confidently.

In addition to the Accelerate book, here are some resources I found invaluable:

• Brian Finster's talk: How to Misuse DORA DevOps Metrics

• Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation book by Jez Humble and David Farley

• Continuous Delivery Pipelines: How to Build Better Software Faster by David Farley

Finally, if you're interested, here’s the GitHub repository containing the database structure and Grafana dashboard we implemented to track and visualize our DORA metrics.

Life is so beautiful,

Fedor

But what about your team’s experience? Have you ever considered how often your developers feel bogged down by their tools? Have you ever introduced a new tool or process to your team only to watch it flop for mysterious reasons?

The truth is, poor usability might be holding your team back, just like it can with your users. We would be much better prepared to tackle complex challenges if we evaluated and improved our team's tools from a usability standpoint, just as we do for our customers.

I’ll share how we integrated security into our development process in this article. It didn’t go well initially, but things turned around when we focused on improving the team's experience.

Surprisingly, Grafana was the tool that played a key role in solving our usability challenges. By leveraging it, we transformed the entire process into something far smoother and more effective for the team. Let me show you how a simple shift in approach made a world of difference.

A Big Change That Didn’t Happen

Our project was 25 years old, and over the years, a significant number of security issues had accumulated. Luckily, our company’s security team had already set up a vulnerability management tool called DefectDojo and linked it to 17 scanners to catch all sorts of problems—vulnerable dependencies, server misconfigurations, leaked secrets, you name it.

The plan was for each team to start fixing security issues in a couple of repositories. As the team progressed, the security team would expand the scans to more repositories until we had improved security posture across the company.

But after a year, neither my team nor others had really made much progress. The security team had done their part, so why weren’t we fixing the issues?

Maybe I need to start micromanaging and pushing my team harder to focus on security? I prefer to believe people have good intentions. Instead of asking, “Why don’t my teammates want to improve security?” I asked, “Do the tools we have help to take action?”

A quick check confirmed the problem. Then, I reworked the given tools. And guess what? In the next four months, we eliminated 7700 findings (97% of our security issues) and made security a usual part of our development process.

Spotting the Problem with the Tools

I spent some time using DefectDojo myself to try and fix security issues. I quickly saw why the team was struggling.

1. High Cognitive Load

DefectDojo was overwhelming, especially for those of us who aren’t security experts. The workflow wasn’t intuitive, and even filtering issues to figure out what to tackle next felt complicated:

The scanners flagged around 800 issues with just two repositories configured and that was already overwhelming. But we had 30 more repositories to configure!

2. Poor Performance

Our initial DefectDojo setup wasn’t optimized, so each user action took 10–15 seconds. The security team improved this over the next six months, but we needed to clear our backlog faster, and waiting wasn’t an option. So, I offered the security team our help with database tuning but continued researching alternatives.

3. No Feedback Loop or Sense of Progress

After a week of fixing 50 issues, I felt like I’d barely made a dent. It was like taking a cup of water from a lake. With 30 more repos to configure, I knew we’d find thousands more issues, and in front of such a volume, I simply gave up.

Moreover, new issues kept popping up while I worked on the old ones. I had no idea if my effort was even making a difference. I couldn’t answer the simplest questions: Am I making progress? Are new issues appearing faster than I can fix them?

Reducing the Friction

To fix these issues, I dove into DefectDojo’s domain model, API, and internal database structure. Eventually, I decided to pull the data into Grafana for better visualization.

I created an SQL view to safeguard sensitive data and grant limited access, ensuring the process was secure. I was also concerned about the tight coupling with DefectDojo's database structure. Still, after a year and several DefectDojo updates, the created view never broke, proving this solution is reliable enough.

It took me two days to implement and demonstrate the initial dashboard to my teammates. I then spent another couple of days tweaking it based on their feedback and sharing it with our managers to ensure they could see our progress, too.

Here are the essential sections of the resulting dashboard:

The dashboard completely solved performance issues due to direct database reads. Additionally, it masked DefectDojo’s complexity and minimized cognitive load since we were familiar with Grafana and loved it.

The biggest win was how easy it became to filter issues based on what we needed to work on next. Now, the team could glance at the dashboard, see what needed attention, and get started—no more complicated filtering or jumping between tools.

But the final piece of the puzzle was providing a real sense of progress.

Making Progress Feel Tangible

I wanted simple yet meaningful indicators to capture both the number and severity of security issues. Fixing a complex, high-severity issue should be as rewarding as fixing dozens of low-severity ones.

So, I added a “Vulnerability Index,” where each issue had a numeric weight based on severity: Info/Low = 1, Medium = 10, High = 100, Critical = 1000. We began tracking it alongside the raw number of findings.

Next, I decided to make the history of previous efforts very visible.

Goodhart's Law warns that when a metric becomes a goal, people tend to manipulate it, intentionally or not.

So, If we only track the current findings count and Vulnerability index, we might be tempted to keep these numbers low by... not adopting new scanners.

I wanted to encourage curiosity and proactivity instead. So, an increased metric shouldn't be discouraging. By looking at our past ups and downs, we can say, "This spike is from when we integrated Scanner X, and here's how long it took to fix all the issues it found."

With this in mind, let’s return to the dashboard's "Overview" section. It displayed the findings count (in orange), the Vulnerability Index (in blue), and their historical trends:

This visual representation of progress made everything feel more tangible. We’d run a security scan every time we fixed something and see the numbers drop. It was incredibly satisfying, almost like a game — the dopamine hit kept us motivated!

Armed with this dashboard, we activated every available scanner across all 30 repositories and started improving our security posture as of August 2023.

Of course, creating the dashboard was just the beginning. While it made investigating issues much easier, the next challenge was streamlining the process of solving them.

Streamlining the Issue-Solving Process

Our idea of streamlining was simple: gradually move to a point where fixing a security issue is the easiest choice, easier than discussing its importance or priority.

One area we focused on was third-party tools. When a vulnerability is found, we can check its impact, review network access to our tool, and decide whether to fix this vulnerability. Another option is to leverage Infrastructure as Code (IaC) and make a no-brainer update to the latest version instead of analyzing the vulnerability. This is a very beneficial strategy, considering the repeatable nature of security efforts. If moving to IaC seems too much work, at least you can containerize the tool using Docker and track new versions that way.

We took the same approach with secrets management. We could investigate every secret found to check whether it was a test secret, whether the production value differs, whether this secret appeared in release artifacts, and whether there are chances that it leaked outside. Another option is to adopt a secrets management system like Vault and reroll such secrets in the first place. We chose the latter.

The same works with dependency management. However, this topic deserves a separate section in the article.

Automating Dependency Management

About 40% of our security issues were related to vulnerable dependencies. Updating dependencies is repetitive, so the more we can automate, the better. Ideally, we wanted to "shift left" and update all dependencies on day zero—before vulnerabilities became widely known.

To achieve this, we adopted the Renovate bot. This powerful tool tracks all our dependencies—Java, Python, JavaScript, Docker, and Gradle—and automatically creates pull requests whenever a new version is available.

Even though Renovate’s documentation is great, configuring it for a large-scale project like ours took time. I spent two weeks setting it up and working through dependency updates to ensure the team would get everything they needed. Once I felt confident, I introduced Renovate to the team, made myself available for questions, and fine-tuned the configuration based on teammates’ feedback.

I recommend following their best practices and user stories if you're starting with Renovate. Below are a couple of additional tips from our experience.

Weekly Batch Updates

We run Renovate weekly and set it up to group all non-major dependency updates into one pull request per repository. We also use a consistent branch name for these pull requests. This setup lets us automatically create a staging environment and run unit and end-to-end (e2e) tests on the proposed updates.

This approach helps us catch potential issues, including runtime errors while sleeping. By the time the team begins their work, all checks are already completed, reducing the noise from constant updates.

Here’s the grouping preset we used:

{
      "groupName": "all non-major dependencies",
      "matchDatasources": ["maven", "npm", "pypi"],
      "matchUpdateTypes": ["digest", "patch", "minor"],
      "matchPackagePatterns": ["*"],
      "branchName": "renovate-non-major-updates-batch"
}

Codeowners Plugin for Reviewer Assignments

Another great addition to our setup was the Codeowners plugin. This tool works with all popular source control management systems and automates the assignment of reviewers for pull requests. We configured it as follows:

• If a person manually starts the Renovate pipeline, they are automatically assigned the related pull requests.

• If a scheduler starts the pipeline, the pull requests are assigned to the engineer on third-line support duty.

• For larger or more complex repositories, the reviewer is randomly selected from the Codeowners list to ensure no one is overwhelmed by constant Renovate updates.

With this setup, we avoided burdening individual team members with repetitive PRs while ensuring all dependencies were regularly updated.

Integrating Developed Tools Into Existing Workflows

One of the biggest challenges in software development is dealing with constant context switching. Developers often have to juggle a variety of disjointed tools—CI/CD systems, source control, task trackers, observability tools—and this back-and-forth can really slow things down.

When we started our security journey, we already had a custom Slack bot in place, which was a great foundation for improving our overall security workflow. I previously wrote on how you can create your bot from scratch. Here’s how we improved this bot to streamline our security efforts:

• Slack Commands for Renovate: We set up Slack commands to run Renovate scans and check on existing pull requests, eliminating the need to switch between the CI tool and the source control system. Everything could be done from within Slack.

• Integrated Renovate PRs management: Whenever Renovate creates a pull request, the assigned reviewer receives an instant notification in Slack, complete with release notes. The reviewer was also kept in the loop about build statuses and test results.

• Integrated Notifications: The team got periodic reminders about pending Renovate PRs that needed attention. In addition, we configured Grafana to send alerts about emerging security issues directly to Slack, allowing us to respond quickly.

These changes drastically reduced the need to switch between different systems. We don’t have to remember to check DefectDojo or Grafana to stay on top of security issues — they come to us in Slack. Plus, we can update dependencies without ever leaving Slack, making the whole process more efficient and keeping the team more focused.

Over the past year, Renovate has created over 1,200 pull requests for us. This helps us keep up with vulnerabilities and update dependencies easily, allowing the team to focus on more important tasks.

Conclusion

In just 12 months, we eliminated 99% of the security debt accumulated over the past 25 years. More importantly, we integrated security into our development process to ensure continuous improvement moving forward.

Here’s a snapshot of the entire journey in one simple graph showing Created (red) vs. Resolved (green) issues:

The key to success was providing the team with the right tools and making ongoing improvements based on their feedback.

All the changes I’ve mentioned took just 17 workdays — a small fraction of the overall security efforts. Plus, it wasn’t just my team that benefited — other teams have also adopted and benefitted from our tools.

If you're interested in learning from our experience, feel free to explore the Grafana dashboard, SQL view, and Renovate pipelines mentioned in this article.

Do you have your own story of improving developer experience to drive success? Please share it in the comments!

Life is so beautiful,

Fedor

How many different tools do you need to roll out a change to production and verify that it was deployed successfully?

This abundance introduces context switching, which can seriously harm developer productivity. Some tools offer plugins to bridge the gaps, but these are often too generic and still require developers to hop between them to complete a meaningful task.

Fortunately, we can address this issue by building custom integrations tailored to our needs. But where should these integrations live?

For my team, Slack has become the perfect hub for these integrations. Unlike the IDE, where focus is key, Slack is where we naturally transition into collaborative or operational tasks. Additionally, it has robust API and SDK, making it an ideal platform to centralize workflows, automate tasks, and streamline processes without disrupting developers’ focus.

The Slack API has a learning curve, but adding new integrations becomes straightforward once you overcome it. This article aims to guide you through that initial learning curve with a comprehensive, step-by-step approach, helping you quickly reach a point where implementing the automation you need is easy. We’ll integrate Slack with Jenkins to manage pipeline executions entirely within Slack.

The complete source code for this project is available on GitHub. While I used TypeScript, Slack also provides Java and Python SDKs.

Below is a preview of a basic scenario: a user sends a Slack command, selects a pipeline, fills in parameters via a generated form, and triggers the pipeline—all without leaving Slack.

Preparing the Environment

Registering a new Slack application

To get started, we need to create a new Slack application. I recommend setting up a separate Slack workspace for testing and following the "Create an app" section in the Slack Bolt Getting Started guide.

To streamline the process, you can import a prepared manifest file during configuration. This file will automatically configure the necessary scopes, enable event handling, and register the required Slack command.

Once you've registered and installed the app in your Slack workspace, you’ll need to obtain two tokens:

• App Token can be generated on the Basic Information page.

• Bot Token can be obtained from the OAuth & Permissions page.

Bootstrapping an Application Repository

You can either clone my repository and follow the steps in README.md or continue with the Slack Bolt guide to bootstrap the app manually.

Start by installing the required npm dependencies:

npm install @slack/bolt axios dotenv ts-node typescript

Next, set up the Slack Bolt app in the app.ts file. Here’s an example setup:

import {App} from "@slack/bolt";
import {AppConfig} from "./app.config";

const app = new App({
    token: AppConfig.SLACK_BOT_TOKEN,
    appToken: AppConfig.SLACK_APP_TOKEN,
    socketMode: true
});

(async () => {
    await app.start(AppConfig.SLACK_BOT_PORT);
    console.log("⚡️ Jenkins-Slack connector is running!");
})();

The AppConfig is a simple wrapper for environment variables:

import "dotenv/config";

export const AppConfig = {
    SLACK_BOT_TOKEN: process.env.SLACK_BOT_TOKEN,
    SLACK_APP_TOKEN: process.env.SLACK_APP_TOKEN,
    SLACK_BOT_PORT: process.env.SLACK_BOT_PORT,
    JENKINS_URL: process.env.JENKINS_URL,
    JENKINS_CREDENTIALS: {
        username: process.env.JENKINS_API_USER,
        password: process.env.JENKINS_API_TOKEN
    }
};

You'll also need to export the Slack tokens from the previous step or place them in the .env file:

• SLACK_APP_TOKEN (App token starts with xapp-)

• SLACK_BOT_TOKEN (Bot token starts with xoxb-)

Preparing Jenkins

Next, we need to configure Jenkins to allow API access. Follow these steps to get the required token:

1. Log in to Jenkins.

2. Click your profile name in the upper-right corner.

3. Navigate to Configure in the left-hand menu.

4. Click the Add New Token button to generate a new token.

5. Copy the token for later use.

Now, store the token and your Jenkins login information in environment variables:

• JENKINS_API_TOKEN (your generated API token)

• JENKINS_API_USER (your Jenkins username)

• JENKINS_URL (base URL of your Jenkins instance)

Finally, to test your setup, you can add the following sample pipelines to Jenkins:

Finally, we need some pipelines to test. You can simply add these three sample pipelines to your Jenkins.

Now that everything is set up, we’re ready to dive into the code!

Creating the First Slack Command

The manifest file we used earlier adds a /run_jenkins_pipeline Slack command. Now, let’s write a handler for this command that will display a form allowing users to select and run a Jenkins pipeline.

app.command("/run_jenkins_pipeline", async ({ack, respond}) => {
    await ack();

    const blocks = [
        section("Please, choose pipeline to run"),
        divider(),
        pipelinesDropdown(),
        actionsBlock("submit", [
            button("Run", ActionKeys.RUN_JENKINS_PIPELINE),
            cancelButton()
        ])
    ];

    await respond({blocks: blocks});
});

The code snippet below registers a command handler for the /run_jenkins_pipeline command and performs the following steps:

• Calls the ack() to let Slack know that our app is processing the command.

• Builds a form with a header, a dropdown menu to select a Jenkins pipeline, and two buttons: Run and Cancel.

• Sends form back to Slack by calling the respond() function, allowing the user to interact with it.

Here’s what happens when you run the bot and type /run_jenkins_pipeline in Slack:

With the form now displaying in response to the Slack command, we can move to the next step: teaching the bot how to execute the Jenkins pipeline when the form is submitted.

Running a Parameterless Pipeline

We’ve added the Run and Cancel buttons to the form, but they aren’t functional yet. Let’s fix that by using action handlers to trigger the desired behavior when these buttons are clicked.

The Cancel button is straightforward to implement. Its handler simply responds with a message without taking further action. Here's how it works:

app.action(ActionKeys.DISPLAY_CANCELLATION_MESSAGE, async ({ack, respond}) => {
    await ack();
    await respond("Ok, I've canceled the operation. See you soon.");
});

The Run button is where the magic happens. When a user clicks Run, we need to do the following:

1. Call ack() to notify Slack that we received the action.

2. Extract the selected pipeline name from body.state.values.

3. Start the specified Jenkins Pipeline and return a link to the running job or an error if something goes wrong.

Here’s the handler for the Run button:

app.action(ActionKeys.RUN_JENKINS_PIPELINE, async ({context, body, ack, respond}: AllMiddlewareArgs & SlackActionMiddlewareArgs) => {
    await ack();
    const selectedPipelineOption = body.state.values.pipeline_name.pipeline_name.selected_option;

    try {
        const startedJobUrl = await context.jenkinsAPI.startJob(selectedPipelineOption.value);
        await respond(`:rocket: Here is the running ${link(pipelineDisplayName, startedJobUrl)} pipeline`);
    } catch (error) {
        await respond({blocks: errorMessage(`Unable to run \`${pipelineDisplayName}\` pipeline`, error)});
    }
});

The JenkinsAPI.startJob function is responsible for triggering the pipeline in Jenkins. It sends a POST request to the Jenkins /build API, which returns a queue URL for the job in the location header. After a brief delay, we send a request to the queue URL to retrieve the running job URL from the queuedJobInfo.executable.url property:

export class JenkinsAPI {
    private readonly auth: BasicAuthCredentials;
    private readonly jenkinsUrl: string;

    constructor(auth: BasicAuthCredentials, jenkinsUrl: string) {
        this.auth = auth;
        this.jenkinsUrl = jenkinsUrl;
    }

    async startJob(jobName: string, jobParams?: any): Promise<string> {
        const runJobUrl = `${this.jenkinsUrl}/${jobName}/build`;

        const queuedJobUrl = (await this.request(runJobUrl, "POST", jobParams)).headers.location;

        // give Jenkins time to start the job
        await new Promise(resolve => setTimeout(resolve, 300));

        const startedJob = (await this.request(`${queuedJobUrl}/api/json`, "GET")).data;

        if (startedJob.blocked) {
            return Promise.reject(startedJob.why);
        }
        return startedJob.executable.url;
    }
    private async request(url: string, method: Method = "GET", params?: any): Promise<AxiosResponse> {
        return axios.request({
            method,
            url,
            params,
            auth: this.auth,
            headers: {"accept": "application/json", "accept-encoding": "gzip, deflate, br"}
        });
    }
}

In some cases, Jenkins may be unable to start the job (e.g., no available build agent or concurrent job execution is disabled). When this happens, we return an error message to Slack. The queuedJobInfo.why property contains the reason for the failure and is displayed to the user.

So, let's see how it looks in action:

The demo shows a user receives a notification when the pipeline is completed. This is achieved using the Jenkins Slack Notification plugin, which allows us to notify users directly in Slack when the job finishes.

The plugin allows to map the build starter’s email to their Slack user ID and send the notification:

  pipeline {
    ...
    post {
        always {
            script {
                def authorId = slackUserIdFromEmail(currentBuild.rawBuild.getCause(Cause.UserIdCause)?.getUserId())
                if (authorId) {
                    def message = currentBuild.result == 'SUCCESS' ? ":white_check_mark: `${env.JOB_BASE_NAME}` build <${env.BUILD_URL}|completed successfully>" : ":octagonal_sign: `${env.JOB_BASE_NAME}` build <${env.BUILD_URL}|had been failed>"
                    slackSend(message: message, sendAsText: true, channel: authorId, botUser: true, tokenCredentialId: 'jenkins-slack-connector-bot-token')
                }
            }
        }
    }
}

We also use the botUser and tokenCredentialId parameters to ensure the bot sends the message, creating a seamless experience where all messages appear in the same conversation.

Running Pipelines On Behalf Of the User

Currently, we use a single token to interact with the Jenkins API, which means that if our bot is shared with the entire team, all pipelines will be executed under the same user account. This creates a problem: notifications and messages about job statuses will only go to the user who provided the token rather than the individual who triggered the pipeline.

To resolve this, each user should provide their own Jenkins API token. This allows users to run pipelines under their accounts and receive personalized notifications. We can achieve this by using Slack middleware that will:

• Checks for Saved Credentials: If the user has already provided their Jenkins credentials, we initialize the Jenkins API instance and attach it to the context.

• Prompt for Credentials: If no credentials are found, we open a modal form that asks the user to input their Jenkins API token.

Below is the implementation of the middleware:

export async function constructJenkinsAPI({context, client, body, next}) {
    const credentials = CredentialsStore.getCredentials(context.userId);
    if (credentials) {
        context.jenkinsAPI = new JenkinsAPI(credentials, AppConfig.JENKINS_URL);
        await next();
        return;
    }
    await client.views.open({
        trigger_id: body.trigger_id,
        view: buildJenkinsTokenModalForm()
    });
    await next();
}

function buildJenkinsTokenModalForm(): ModalView {
    return {
        type: "modal",
        callback_id: ActionKeys.SAVE_ACCESS_TOKENS,
        title: {
            type: "plain_text",
            text: "Access tokens required"
        },
        submit: {
            type: "plain_text",
            text: "Submit",
            emoji: true
        },
        blocks: [
            section("Hi! Please, give me access token to perform useful stuff for you"),
            divider(),
            textbox("Jenkins API token", "jenkins_token")
        ]
    };
}

Also, we need to attach the middleware to all listeners that interact with Jenkins. Here’s how you register it with Slack commands and actions:

app.command("/run_jenkins_pipeline", constructJenkinsAPI, async ({ack, respond}) => {
...
});

app.action(ActionKeys.RUN_JENKINS_PIPELINE, constructJenkinsAPI, async ({context, body, ack, respond}) => {
...
});

The middleware will ensure every user has valid credentials before proceeding with the command or action.

The next piece is implementing the Slack view listener called when a user submits the token form. here, we need to save user credentials and confirm the process was successful:

app.view(ActionKeys.SAVE_ACCESS_TOKENS, constructUser, async ({ack, body, context})=> {
    const respond = async (title: string, ...blocks: any[]): Promise<void> => {
        await ack({
            response_action: "update",
            view: {
                type: "modal",
                title: {type: "plain_text", text: title},
                blocks: blocks
            }
        });
    };

    const payload: any = getSlackFormValues(body.view.state.values);
    const userInfo = (await client.users.info({user: context.userId})).user;

    CredentialsStore.saveCredentials(context.userId, {username: userInfo.profile.email, password: payload.jenkins_token});

    await respond("Success", section(":thumbsup: Token was saved. Now you can use any of my features"));
});

Let's also look to the CredentialsStore used above. It simply saves tokens in memory:

import {BasicAuthCredentials} from "./jenkins-api/BasicAuthCredentials";

const CREDENTIALS_STORE: Record<string, BasicAuthCredentials> = {}

export class CredentialsStore {
    static saveCredentials(userId: string, credentials: BasicAuthCredentials): void {
        CREDENTIALS_STORE[userId] = credentials;
    }

    static getCredentials(userId: string): BasicAuthCredentials | null {
        if (userId in CREDENTIALS_STORE) {
            return CREDENTIALS_STORE[userId];
        }
        return null;
    }
}

With this setup, each team member can now run Jenkins pipelines using their own credentials.

Running a Parameterized Pipeline

Now that we've handled simple, parameterless pipelines, let’s modify our bot to support running parameterized pipelines as well.

In the updated handler for the /run_jenkins_pipeline command, we first check whether the pipeline requires parameters. If it does, we present the user with a form to input those parameters. If not, we simply run the pipeline as before:

app.action(ActionKeys.RUN_JENKINS_PIPELINE, async ({body, ack, respond}: AllMiddlewareArgs & SlackActionMiddlewareArgs) => {
    ...
    const pipelineParameters = await jenkinsAPI.getJobParameters(pipelineId);

    if (pipelineParameters) {
        const parametersForm = buildPipelineParametersForm(pipelineParameters, pipelineDisplayName, pipelineId);        
        await respond({blocks: parametersForm});
    } else {
        await runParameterlessPipeline(context.jenkinsAPI, pipelineId, pipelineDisplayName, respond);
    }
});

The key part here is calling the getJobParameters method from our Jenkins API class to retrieve the pipeline’s parameter definitions:

export class JenkinsAPI {
    ...
    async getJobParameters(jobPath: string): Promise<JenkinsParameterDefinition[] | null> {
        const url = `${this.jenkinsUrl}/${jobPath}/${JENKINS_API_POSTFIX}`;

        const jobInfo = (await this.request(url, "GET")).data;
        const parametersDefinition = jobInfo.property.find((item: object) => "parameterDefinitions" in item);

        return parametersDefinition?.parameterDefinitions || null;
    }
}

If no parameters are needed, we run the pipeline immediately by calling the runParameterlessPipeline function. It runs parameterless pipeline the same way we implemented previously:

async function runParameterlessPipeline(jenkinsAPI: JenkinsAPI, pipelineId: string, pipelineDisplayName: string, respond: RespondFn) {
    try {
        const startedJobUrl = await jenkinsAPI.startJob(pipelineId);
        await respond(`:rocket: Here is the ${link(pipelineDisplayName, startedJobUrl)} pipeline that you run`);
    } catch (error) {
        await respond({blocks: errorMessage("Unable to run pipeline", error)});
    }
}

For parameterized pipelines, we display a parameters form to the user. Here’s the buildPipelineParametersForm function that builds that form:

function buildPipelineParametersForm(pipelineParameters: JenkinsParameterDefinition[], pipelineDisplayName: string, pipelineId: string) {
    return [
        section("Please, specify parameters"),
        divider(),

        ...mapJenkinsParametersToSlackControls(pipelineParameters),

        actionsBlock(pipelineId, [
            button("Run", ActionKeys.RUN_PARAMETERIZED_JENKINS_PIPELINE, pipelineDisplayName),
            cancelButton()
        ])
    ];
}

The mapJenkinsParametersToSlackControls function maps each Jenkins parameter type to the appropriate Slack UI control. While the complete implementation is more complex, here’s a simplified version that handles common parameter types:

function mapJenkinsParametersToSlackControls(parametersDefinition) {
    return parametersDefinition.map(parameter => {
        const controlName = humanizeParameterName(parameter.name);

        switch (parameter.type) {
            case "StringParameterDefinition":
                return textbox(controlName, parameter.name, parameter.initialValue);
            case "TextParameterDefinition":
                return textarea(controlName, parameter.name, parameter.initialValue);
            case "ChoiceParameterDefinition":
                return staticSelect(parameter.name, getSelectOptions(parameter), parameter.name);
            case "BooleanParameterDefinition":
                const initialOption = {[parameter.name]: humanizeParameterName(parameter.name)};
                return checkboxGroup(" ", parameter.name, initialOption, parameter.initialValue ? initialOption : undefined);
            default:
                throw new Error(`Unknown control type ${parameter.type} of the field ${parameter.name}`);
        }
    });
}

The last step is implementing another action handler that triggers the pipeline with the provided parameters once the user submits the form. The submitted values are collected with the getSlackFormValues function and passed to the jenkinsAPI.startJob method:

app.action(ActionKeys.RUN_PARAMETERIZED_JENKINS_PIPELINE, async ({context, body, payload, ack, respond}) => {
    ack();

    const pipelineId = payload.block_id;
    const submittedValues = getSlackFormValues(body.state.values);

    try {
        const startedJobUrl = await context.jenkinsAPI.startJob(pipelineId, submittedValues);
        await respond(`:rocket: Here is the ${link(payload.value, startedJobUrl)} pipeline that you run`);
    } catch (error) {
        respond({blocks: errorMessage("Unable to run pipeline", error)});
    }
});

Let's look at the complete use case in action:

Now, with the parameterized pipeline support in place, we can:

1. Run simple, parameterless pipelines.

2. Receive Slack forms for parameterized pipelines, fill them out, and trigger the pipeline with their custom input.

Next, we’ll explore a more complex use case for handling interactive pipelines.

Adding Interactivity With Jenkins Input Step

The Jenkins Input Step allows you to create interactive pipelines by asking for user input during pipeline execution. If you have never seen it in action, here is how it looks in Jenkins UI:

This can be highly useful for complex deployment processes, allowing teams to make decisions in real-time, such as determining which services to deploy or whether to roll back a deployment.

This feature was especially useful when developing a new delivery pipeline for my project. It allowed me to implement a complex deployment process, allowing the team to make real-time decisions on whether to send release notes and what Jira tasks to mention, what environments to update, which services to deploy, and whether to roll back to a previous version if the deployment was unsuccessful.

So, let's integrate this awesome feature into Slack, too!

1. Declaring Input Step in the Pipeline

First, let's see how the Input Step is defined in the Jenkins pipeline:

pipeline {
...
stage('Test stage 2') {
  steps {
      script {
         input(
            id: 'some-approval',
            message: 'Please, choose parameters and press "Continue"',
            parameters: [
                stringParam(name: 'someStringParam', defaultValue: '', description: 'Some string popup param'),
                booleanParam(name: 'someBooleanPopupParam', description: 'Some boolean popup param')
            ],
            ok: 'Continue')
    }
  }
}
...
}

Note that we explicitly pass the unique id parameter. If the pipeline has multiple input steps, this prevents submitting a form for the first input while the pipeline has already requested the second one.

2. Notifying Slack Bot About Input Request

We should somehow notify the Slack bot that the pipeline requested user input. We will do that by sending a Slack message. Even though we will intercept this message in the next step, I prefer to make it human-readable. This will work as a fallback, allowing the user to follow the link and provide input with Jenkins UI ​​even if the bot fails to complete its task.

def sendInputRequestToTheSlack() {
    def authorId = slackUserIdFromEmail(currentBuild.rawBuild.getCause(Cause.UserIdCause)?.getUserId())
    if (authorId == null) {
        return
    }

    def message = ":keyboard: <${env.BUILD_URL}|${env.JOB_BASE_NAME}> requested some input. <${env.RUN_DISPLAY_URL}|Please, provide it here>"

    slackSend(message: message, sendAsText: true, channel: authorId, botUser: true, tokenCredentialId: 'jenkins-slack-connector-bot-token')
}

Now, we need to configure the Slack bot to listen to messages.

First, we should disable the ignoreSelf option so the bot can listen to its own messages:

const app = new App({
    token: AppConfig.SLACK_BOT_TOKEN,
    appToken: AppConfig.SLACK_APP_TOKEN,
    socketMode: true,
    ignoreSelf: false
});

We have already enabled event listening with the manifest file. It’s disabled by default since Slack generates tons of events.

settings:
  event_subscriptions:
    bot_events:
      - message.im

3. Listen to the Notification in the Slack Bot

Now, we're ready to implement the message listener:

app.message(async ({context, message, client}) => {
    if (context.botId != message.bot_id && message.text.indexOf(":keyboard:")!==0) {
        return;
    }
    const [{url: buildUrl, text: buildName}, {url: buildDisplayUrl}] = message.blocks.flatMap(b => b.elements).flatMap(e => e.elements).filter(e => e.type == "link");

    // give Jenkins time to render the input
    await new Promise(resolve => setTimeout(resolve, 300));

    const jenkinsInputDefinition = await context.jenkinsAPI.getJobPendingInput(buildUrl);
    const formBlocks = jenkinsInputDefinition? await buildJenkinsPendingInputForm(buildUrl, jenkinsInputDefinition) : buildInputHandlingFailureForm(buildName, buildUrl);

    await client.chat.update({
        channel: message.channel,
        ts: message.ts,
        blocks: formBlocks,
    });
});

This code does the following:

• It checks if the message is from the bot and starts with a ⌨️ emoticon. This way, it only handles messages about Jenkins Input Requests.

• It extracts the running job's URL and name from the message blocks.

• It fetches the pending input definition by calling the jenkinsAPI.getJobPendingInput , which is very similar to already known jenkinsAPI.getJobParameters.

• If the input definition is empty, someone has already submitted input, or a timeout was reached. In that case, it shows the error form by calling buildInputHandlingFailureForm function.

• Otherwise, we show the parameters form by calling the buildJenkinsPendingInputForm function. This maps Jenkins parameters to Slack controls, as we saw in the “Running Parameterized Pipeline” section.

4. Handling Input Form Submit

We're almost done. All that's left is to submit or cancel pending input depending on which button the user clicks on the rendered input form. Here is the submit handler:

app.action(ActionKeys.SUBMIT_PENDING_JENKINS_INPUT, async ({context, body, ack, respond}) =>{
    ack();

    const submitUrl = body.actions[0].value;
    const buildUrl = body.actions[0].block_id;

    const submittedValues = getSlackFormValues(body.state.values);

    try {
        await context.jenkinsAPI.submitJobPendingInput(buildUrl, submitUrl, submittedValues);

        await respond(`Input was submitted to the ${link("build", buildUrl)} by ${body.user_name}`);
    } catch (error) {
        await respond({blocks: errorMessage(`Unable to submit input for the ${link("build", buildUrl)}`, error)});
    }
});

As you can see, it is almost identical to the handler we implemented to run the parameterized pipeline. The only difference is that we call the jenkinsAPI.submitJobPendingInput instead of the jenkinsAPI.startJob.

Here is the listing of the jenkinsAPI.submitJobPendingInput method:

export class JenkinsAPI {
    ...
    async submitJobPendingInput(buildUrl: string, submitUrl: string, formValues: any): Promise<void> {
        const inputDefinition = await this.getJobPendingInput(buildUrl);

        if (!inputDefinition || !submitUrl.includes(`inputSubmit?inputId=${inputDefinition.id}`)) {
            throw new Error("Input was already submitted or timed out");
        }

        const convertedValues = Object.entries(formValues).map(([key, value]) => ({name: key, value}));
        await this.request(`${this.jenkinsUrl}${submitUrl}`, "POST", {json: JSON.stringify({parameter: convertedValues})});
    }
}

We request pending input from Jenkins again to ensure that the input is still expected and its ID matches the submitted input's ID. Then, we convert the submitted values to the Jenkins API format and post them.

5. Handling Input Request Abortion

The last step is to handle input abortion. Here is the code of the handler:

app.action(ActionKeys.ABORT_PENDING_JENKINS_INPUT, await ({ context, body, ack, respond }) => {
    await ack();

    const abortUrl = body.actions[0].value;

    try {
        await context.jenkinsAPI.abortJobPendingInput(abortUrl);
        await respond(`Input was aborted by ${body.user_name}`);
    } catch (error) {
        await respond({ blocks: errorMessage("Input abort failed", error) });
    }
};

Here, we simply call the jenkinsAPI.abortJobPendingInput method and notify the user about the abortion.

The code of the jenkinsAPI.abortJobPendingInput method is very straightforward:

 export class JenkinsAPI {
    async abortJobPendingInput(abortUrl: string): Promise<void> {
        await this.request(`${this.jenkinsUrl}/${abortUrl}`, "POST");
    }
}

Well, we're finally done! Let's see the magic in action:

Well, we implemented the latest use case!

Generally, we've covered many features of the Slack Bolt SDK and built a comprehensive automation. However, to keep the article easy to read, I skipped error handling, monitoring, logging, security, and testing (but you can check the source code for tests).

Wrapping Up

Integrating Slack with your development tools can elevate your workflow by enabling seamless communication, automation, and collaboration. The true power of such an integration is its ability to connect multiple systems and surface relevant information when needed. Imagine starting your workday with a Slack bot that does the following:

• It lists tasks you've recently closed and suggests follow-up actions like updating documentation or notifying relevant stakeholders.

• Displays pull requests you’ve participated in that are awaiting review or haven’t been merged yet, ensuring nothing slips through the cracks.

• Shows your next task, along with its recent updates or comments, so you're always in sync with ongoing discussions.

• Lists branches you've worked on that lack pull requests, helping you identify abandoned work or unfinished experiments.

• Presents recent findings from automated security scans, ensuring security issues are addressed quickly.

• Highlights unresolved threads from Slack channels that need your or your team's attention, streamlining internal communication.

• If the number of unresolved support tickets spikes, the bot could offer you to help your on-call teammate.

By automating these workflows and integrating them into Slack, you can create a cohesive environment tailored to your team’s needs, improving productivity and collaboration.

I hope this guide has equipped you with the tools and knowledge to build your Slack-powered development environment, streamlining your daily operations and enhancing your team's effectiveness.

Life is so beautiful,

Fedor