The hired gun for teams that couldn’t ship

The situation

Some development teams have everything a product needs except the ability to finish it. The idea is sound, the people are capable, and the work is real, yet the application never quite reaches the market. Other teams are starting something new and know that the decisions they make first will be the hardest to undo.

I started Spotless Software as a hired gun for teams that were having problems shipping their products. I owned the company and was the managing member of the LLC. To grow the business while I worked with the technical teams, I brought on two other executives, one as Marketing Officer and one as Business Manager.

From the company’s point of view, my job was to be its technical visionary, and that began with deciding which teams we agreed to help. Once we took a team on, I worked inside it as its lead architect and engineer.

Engagements were usually private. We were never the face of a client’s company, and nobody brought us in to take an already accomplished team to the next level. We came in to tell a team where it had gone wrong and help put it right: coaching its managers, its leads and its developers, and fixing the software and the deployments along the way. Sometimes that meant being a sounding board. Other times it meant sitting in the room as the team’s management layer until we found the person who should fill that role. For founders with an idea and no idea how to grow it, we became the executive layer outright, until they could make money and hire people to replace us.

Why teams stall

Teams that can’t ship rarely fail for a single reason. The work I did with each team kept returning to the same handful of problems, and they usually arrived together. They aren’t the only reasons, but they are the big ones.

• No working process. Without a steady rhythm of planning, prioritizing and demonstrating work, no one could say how close the product was to done.
• Weak foundations. Struggling projects often carried architecture and code that had to be audited and corrected before anything built on top of them would hold.
• Engineering and DevOps bottlenecks. A single blocked build, environment or integration could stall everyone behind it.
• The wrong mix of people. Some teams had people who were holding the work back; others were simply missing the skills they needed.
• Distance from commercial reality. Some developers had not yet aligned with what it takes to build sustainable, commercial-grade software.

None of these is a talent problem. Each is a problem with the system the team is working inside, and each can be fixed.

The approach and the decisions behind it

Every team was different, but the way I engaged with them followed a few consistent decisions.

Choose the teams deliberately.

Spotless did not take on every team that asked. Deciding which teams we would help was the first technical judgment of every engagement, and the one I owned at the company level.

Start with an honest audit.

For struggling projects, I audited the codebase and the architecture first, then made targeted technical corrections rather than starting over by reflex.

Lead from inside the team.

I didn’t advise from a distance. I worked in the trenches with the engineers, engineering their data, APIs and user interfaces, keeping the energy up and working through the engineering and DevOps bottlenecks with them.

Fix the process, not just the code.

I taught teams Agile and Scrum and ran the ceremonies with them: daily standups, sprint planning, prioritization, backlog grooming, retrospectives and stakeholder demos.

Make quality automatic.

Every development team worked from standardized CI/CD pipelines, built with tools such as Jenkins and Bitbucket Pipelines, with unit tests, end-to-end tests and code-quality checks as a mandatory step in every pipeline before anything was deployed.

Get the right people in the seats.

I helped teams with staffing: assessing skills, finding the people who were holding the work back, restructuring where necessary, and finding new people to join.

Build products, and teams, that stand on their own.

The aim was never a fast demo. It was a sustainable product and a team capable of carrying it after we stepped away. The best result of an engagement was a team that no longer needed us. That was a moment of pride, a little like a parent sending a child out into the world: go forth, you’ve succeeded, and we’re here if you need us.

How an engagement worked

Spotless itself was small at the top and broad underneath. I set the technical direction and worked directly with each team, a core staff of full-time developers carried that direction across many projects at once, and a much larger network of client and partner teams worked to the same standards.

With each team, the work moved through the same broad stages, though rarely in a straight line.

1. Deciding to help. I looked at the team, the product and the problem, and decided whether Spotless was the right partner for it.
2. Finding out what was really wrong. For a struggling project, that meant an audit of the codebase and architecture. For a new one, it meant settling the architecture before the first features were built.
3. Steering and teaching. I set the technical direction and taught the team Agile and Scrum, running the ceremonies with them until the rhythm held on its own.
4. Engineering alongside them. I worked on the data, APIs and user interfaces myself, cleared engineering and DevOps bottlenecks, and put the team on standardized pipelines with automated testing. Spotless kept its own hosting environment where a team could start porting and preparing its code, but the aim was always to get each team onto its own hardware and hosting, with me in the DevOps role until it got there.
5. Getting the team right. I helped identify the people holding the work back, assessed skills, and found new people to join, whether as full-time staff or consultants.
6. Getting ready for investors and the market. I coached teams on finding investors and on the questions investors would ask. Is this the right technology? Is the product viable? Will people want it? Can it make money? What does the market research say? Many times we brought our own investors. But the pitch always belonged to the team. We were a hired gun, there to give them those abilities, not to be the face of their company.
7. Stepping away. The engagement was finished when the team could stand on its own two feet. We didn’t stay on after a team raised capital or sold, unless its investors asked us to.

Outcomes

Spotless measured itself by what happened after the code was written: whether a product found investment, a buyer or a market, and whether the team was more capable at the end than at the start.

• More than a hundred applications architected across web, mobile and enterprise platforms, including mobile applications delivered through the Apple App Store and Google Play.
• Dozens of them went on to attract venture capital investment or were acquired outright.
• About fifty development teams were steered and supported, with developers across the United States, Canada, South America, Prague, India and Russia.
• One engineering standard. Standardized CI/CD pipelines, with automated testing and code-quality checks mandatory in every one, gave every team the same safety net.
• Honest endings when they were needed. Teams that brought us in usually knew something was wrong, and there are a lot of emotions at stake in that situation. Some teams, for reasons rooted in their people and personalities, couldn’t or wouldn’t adapt. We never wanted to force anyone, but if we didn’t believe we could succeed, we needed to walk away.

My role

I founded Spotless Software and owned it, serving as the managing member of the LLC. I brought on a Marketing Officer and a Business Manager to grow the business so I could spend my time with the technical teams.

At the company level, I was the technical visionary who decided which teams we agreed to help. Inside each team, I was the lead architect, visionary and engineer: steering the team, teaching Agile and Scrum, engineering its data, APIs and user interfaces, and working in the trenches to keep the energy up and get through engineering and DevOps bottlenecks. I also helped with staffing, from finding the people who were holding a team back to finding the people who should join it. Across the core staff, senior developers served as my second and third in command, so the architecture I set held across many teams at once, and in all I architected more than a hundred applications.