Whenever I’ve joined the engineering leadership for a company and I start meeting my colleagues, the top question seems to always be:

Slow Delivery and Stakeholder Perceptions

“Why is the development of new features always so slow!?!?”. Usually what they mean is: “I have expectations that new features should be delivered faster, and it impacts my department. I don’t understand why!”

It’s important here to define what an “ideal delivery cadence” looks like to people out of the engineering team:

When I look at solving these type of problems, I like to approach it by working backwards. In this case, it would ask myself and leadership “what would ideal product development look like here?” work backwards from there. In other words, what is the opposite of “slow delivery” mean to them.

They probably expect:

1. An understanding of what projects are going to be delivered
2. Knowing when projects are delivered
3. Expecting a regular cadence of those projects being delivered

The first two are really just communication issues that can be resolved pretty easily through better updates and communication. The last one has far more baked in.

How to Use This Guide

Below is a list of challenges that I’ve personally had to work through on development teams to accelerate engineering getting more features out the door faster. As I have more ideas or see more, I’ll update the list so check back again!

Projects take a long time to start

Too much planning: Diplomatic planning

Symptoms You’ll See:

• Lots of meetings around a particular feature/project over weeks (or months!!)
• No clear decision maker or commitment to decision

Other teams have the problem of doing too MUCH planning. Usually this comes from a good place from wanting to get things right on the first try (Big Design Up Front. Some hints this might be the case:

• documentation/specs that are far to many for the scope of the project
• endless meetings to decide on the right approach
• including too many people in the decision-making process, requiring significant energy around alignment and justification.

Some side effects of too much planning:

• wasted effort that could have been better spent in the actual development of the project. The documents that were written will never we reviewed again.
• working through theoretical problems that may or may not be an issue to begin with.
• in the time taken to decide on the approach, the team could have potentially built multiple iterations of the product, likely resulting in being further ahead.

Symptom you’ll see:

• Projects take a long time to move from the “idea” to “in development”.

Too much planning: Building the Perfect

Symptoms you’ll see:

• Lots of work on foundational or generalized components with little feature implementation
• Lots of revision on the design. Aiming for what seems like a perfect solution

Story Time: On a team that I started managing, there was a lone developer who spent the better part of a year building out the foundational parts of the application but hadn’t actually released anything to the world yet. When I dug into to understand their perspective, they were trying to avoid mistakes he has seen in the past: introducing a ton of tech debt into the system and having to eventually having to rebuild the application from scratch. After they shared that story with me, it all made sense: they went to the opposite extreme to prevent the same situation from happening. The downside is creating beautiful code that may never get used by a real user.

Projects in Development Take a Long Time To Finish

“Long Time” is subjective, but you should have a gut feel how long things should take.

Not Enough/Poor Planning of the Feature

Symptom you’ll see:

• Projects that are 90% done but never seem to get out the door.
• Significant delays beyond what the team initially expected

Story time: At one company I joined, there was tremendous pressure from the sales team to build the next feature that would close the next big client. There wasn’t a strong Product team in place to organize and prioritize, so Engineering was left to just tackle effectively whatever the sales team wanted. Due to the pressure, the team felt “there isn’t enough time to plan” and jumped right into the code. Of course, they would code themselves into a corner by adding band-aid features on top of other band-aid features. After years of this, there was a mountain of tech debt that had never been repaid and development time on the most basic feature had stalled. By insisting the team pick a minimum time to plan the feature (a few days to two weeks), the predictability of the delivery improved significantly.

How this happens: Out of enthusiasm or out of false confidence, some teams spend very little time actually taking the time to go deep into the design of a particular feature. They feel that there isn’t enough time to plan and should just tackle the feature right away and figure it out as they go. Even when the solution seems very obvious, it takes discipline to step back, map out the unknowns/risk parts, do investigations, and work with others to improve the design BEFORE jumping in to code right away. This effectively means that the last part of the implementation often takes far longer than ever anticipated. Having proper planning to work through the details to nail down how it will work up front can mitigate a lot of this.

There is a famous principle called Ninety–ninety rule - Wikipedia coined by a famous engineer at Bell Labs:

The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time." - Tom Cargill

This can usually only be learned from experiencing the pain of being bitten during the development cycle by a missed detail that could have been found during the design phase.

Recommendation to try:

• For teams new to planning their software design, it will be a hard discipline to slow down and take the time. I’ve seen success using the Shaping Principles from Basement to have a fixed time, but variable scope to de-risk up front.
• For teams who have more experience planning up front, coming up with a standard set of artifacts that the engineering team need before starting development might be enough to ensure enough planning is done up front.
• deep dive into rabbit holes that might cause issues down the line, and do quick spikes (throw away code to test an idea) to validate a thing will work.

Poor Product/Engineering Relationship and Artifacts

Symptom you’ll see:

• Lots of confusion by developers during the development.
• Product managers surprised/frustrated by how the feature works.

Product Management should be putting together everything that the engineering team needs so they can hit the ground running once development starts. These artifacts look different for every team, but here are some ideas:

• Business case and problem defined in detail for the project. When engineers have a lot of context around the why this project is important, they are empowered to make better decisions in the details of the implementation.
• Designs - Maybe Engineering needs some very rough sketches to know the layout. In other cases, very detailed designs are appropriate. In any case, don’t leave it too ambiguous.
• User Stories/Tickets - Depending on the seniority of an engineer, they may or may not be able to break down large projects into smaller ones. For example, more junior engineers can only be expected to work on smaller sized tickets that have quite a bit of detail on them. Seniors on the other hand, can take large projects without too much detail and break them down into smaller bite-sized tickets.
• What is NOT included in the project - We’ve all had projects that had developed scope creep. Sometimes it’s the product manager who wants to add “just one more detail” to the feature. In many cases, the engineering team overengineers the solution to accommodate potential use cases in the future that likely won’t happen. Helping the team know the boundaries of the project is powerful.

Distracting Bugs and Outages

The team who did the development of a project has the most context about it, resulting in that team ultimately doing the bug fixes.

However, every bug and outages that comes onto the engineering team’s plate is energy that is taken away from building new revenue generating features.

Is these bugs need to be fixed right away, there are two things that these causes:

1. The actual time required to make that fix
2. The additional (and sometimes) massive context switch for the individual who will be working on it.

The team should have a process in place to handle bugs while the team not distracted from their main project that they are currently worked on.

Recommendations to try:

• If bugs regularly come up, plan for that! Set up a bug rotation where one of the team members has no allocation of project work for that rotation. Instead, they are fully dedicated to the support team and crushing whatever comes up. This protects the team from being too distracted.
• Likely some bugs can be tackled later on. If so, ask your product manager to triage them and schedule them for a later sprint, so the team can keep focused on the current plan.

Other distracting requests

Outside of bugs, there are often one-off requests that in from different parts of the company that also take time from the engineering teams:

• CX: “How does this feature work? A customer is asking”
• CEO: “I have this cool idea. How long do you think it would take to build?”
• Performance reviews
• Incidents
• Design asking what’s possible
• Data reporting for management
• Any number of other things

A further complicating factor is that these are often not asked in a public channel but as DMs to individuals who the originator knows is the right person. So getting a handle on understanding if/where these type of requests are coming from can be tricky.

Recommendations to try:

• As you hear about requests via DM, recommend the person they re-request it in a recommended channel. That way it will have more visibility and the support for those can be passed around with a potentially faster turn around.
• If you have good rapport with your product manager and both you are on the same page on trying to keep the team focused, ask if they are able to be the funnel and triage those requests for you.

One person per project

Sometimes teams what to do ALL THE THINGS instead of prioritizing them. This comes from a good place of trying to make stakeholders happy, but it lacks focus. Ultimately though, what happens? The teams are able to make very slow progress towards a lot of goals at once. There are lots of subtle downsides of having a single person working and delivering a project:

• Very few people with expertise on the project for future changes.
• If that person is away, there is no movement on the project at all.
• No diversity of implementation ideas.
• Slow delivery

Instead, why not put the team as a whole to work on that project together. Synergy and all of that. What does this do?

• Creates momentum by moving a project forward faster.
• Better implementation since there are people with eyes on the project and who are able to make informed code reviews.
• Lower risk - More people who are up to speed on the project and are able to contribute post-delivery. When one person is away from the project, it can still be moved forward by the others.

In my experience, all things being equal: Having the team focus together through prioritized project list outperforms teams where individuals work on projects alone.

Recommendation to try:

1. Do the hard work of prioritizing the projects in a stacked list from top priority down.
2. Share these priorities with stakeholders, so they know what’s coming up.
3. Have the team focus on the top priority project. Once it’s done, have everyone work on the next one.

Too Many Projects in Beta

Based on business needs and with the invention of feature flags, it’s useful to roll out features to a few users first to see how it goes and iterate from there.

However, maintaining these projects in beta has real overhead:

• Having to do small changes based on product feedback (context switching)
• Having to maintain this feature flag and potential collisions with OTHER projects also in beta.
• Cognitive overhead of remembering something isn’t fully out in production and what it will take to get it there.

Recommendation to try:

• Only have one two projects that the team is focused on at a time. Scrum’s “Sprint Goal” is a helpful tool to align around that.
• Have strict criteria about when a project is out of beta and have a time commitment from product on when that is.

Tech Debt

Tackling tech debt is a whole discussion in itself, so I won’t attempt to tackle that here. What I think is helpful here is starting to investigate and structure which tech debt to go after and prioritize.

Recommendation:

• Look at your last few projects that you delivered and think through which parts caused the longest time for delivery. From there you can work through a potential redesign and retroactively look at those projects to see if that new design would have actually accelerated the delivery or not.
• Start a prioritized running list of tech debt that you revisit as a signal on things to change. If you need a rubric to start with I really like the Impact, Fix Cost and Contagion Metrics.

Poor Day-to-Day Discipline

“Agile”, “Scrum”, “ShapeUp”, “KanBan” or whatever are all product development methodologies that I’ve worked with before and I’m opinionated that there is not any universal framework that works for every team.

The key component that I’ve learned is most important for any of these methodologies is a) Having built in metrics to figure out how long things will take to get delivered. b) Have a mechanism for the team to regularly look at what is/isn’t working, and have the ability change the way they are doing.

The key though is picking one and STICK TO IT then iterate.

Recommendation:

• Pick a methodology, use those metrics to find further areas of improve and tweak those changes.

Wrapping Up

What you’ve seen above is my go-to list of ideas to dive into different potential areas where development can go off the rails. Sometimes it’s subtle tweaks, other times the teams need a dramatic change.

Have other ideas that I didn’t capture? Let me know and I’ll try to add them.

Want to talk about this stuff? Send me a note! I write these articles to meet interesting folks and help how I can!

Email: jevin@quickjack.ca

Mastodon: https://mstdn.social/@jevy