Small business, dysfunctional and overloaded; how to convince cultural change?

Question

Joined a small business who’ve built a SaaS platform for a niche and complex business domain. It’s basically “Business Guy” / CEO, “Tech Guy” and “Sales Guy”. The product is clearly valuable with about 20 B2B customers, but the business has stalled as bringing new ones on, combined with customer support, takes up all their time.

After watching and learning for a couple weeks, I think the problem is organizational; just throwing more servers or coders at the problem won’t help.

For example:

• The product (and business problem) is very domain complex and high-touch; each new customer is unique and needs new features, customization, bespoke data formats, etc. This can take months of piecemeal work. Only Tech Guy seems to realize how much this involves.
• Tech Guy built the platform himself over some years. He’s clearly very talented, but the platform exists as much in his head as it does in code. They’ve hired some contractors, but the complexity means only Tech Guy has the knowledge to do much of the work, including technical support and new features. Only he has access to the live site / database, etc., which he describes like a half-finished building with exposed wires, unsecured flooring, that only he can enter safely. Even after six months the contractors cannot act autonomously; Tech Guy must spec everything out in detail, review PRs, etc. They can be idle for days as Tech Guy is too busy with everything else.
• Poor task management: each morning Business Guy writes a list of the “top 10 urgent things” and posts it in Slack for everyone to do. Yes, only the top one or two happen; the rest are re-listed, or forgotten. Many simple things have been "lost" this way, causing customer problems.
• Poor customer management: Business Guy lets customers think they are a larger business, implying each customer gets their own dedicated support. Really, it’s Sales Guy and Tech Guy juggling hot irons in the background. New customers have a weekly status call. In these calls they promise things “by the end of today / tomorrow / the week”, which they often fail to do as a) these calls happen in multiple each day, across all customers and b) tasks are often that only Tech Guy can do them. The calls seem partly done to make sure Tech Guy gets some face time with each customer, or he'd forget them. Some customers have worked out it’s just these two guys and they’re way overloaded; some get angry with Business Guy. And a couple have added Tech Guy to their own Slack and JIRA, pulling him in to their day-to-day like a rent-a-coder.

So! I’ve been hired to generally help out, but they’ve made it clear what they really want is someone to help fix this fun mess and unblock business growth. It has technical aspects, but the cause seems organizational / operational. And unlike this question it's less lack of management as handling of the work itself.

I’m (call me “Organize Guy”?) suggesting a basic approach of visualizing work, and introducing them to concepts like work-in-progress (WIP) limits an theory of constraints:

• A standard task management system, e.g. Trello, to see and track both customer support and internal work and see what's important / stalling. Given the low maturity, I don’t really mind what, as long as they start with SOMETHING.
• Be serious about growing their tech team; identify biggest time sinks (e.g. technical customer support) and train them up. Get Tech Guy to make the internals of the product safer to work with. Get to a place where he can spend time on improving the platform, not running after customers
• The hard one: your business domain is complex, this is not a window cleaning shop. It'll take time and attention, mostly from Tech Guy. This means not overloading him. Respect his time more, protect him from "urgent" work (which is rarely important) and set more reasonable customer timescales than “end of this week”

You guessed it; Business Guy was OK with the first, but less the others. He doesn’t really want Tech Guy to take time out from the tire fire of customer asks, and also wants to increase the new customer rate, complete with status meetings.

I’m not sure how to proceed. I think they need to slow down to speed up, but am unsure how to convince him. What other options may I have missed?

Answer 1

It seems like you've done a good job identifying core elements of the problem, the most crucial being the Theory of Constraints. I feel like it might be worth reframing/reintroducing the theory to the Business Guy. In The Phoenix Project, they give the example of a factory floor with an obvious choke point. All of the inventory clogs up before the choke, so the factory floor is filled with unusable inventory. Reiterate the point that any improvements you make before the choke point will ensure more stuff piles up at the choke point, and any improvements after the choke point will do nothing, because there's not enough getting through to the "after" stage.

In this case, the "Tech Guy" is definitely the choke point, and if you get this "choke point" concept into the heads of the other two leaders, it will help them with the desire to improve his work load. If he's overloaded, they can't get new customers/support old customers/prevent defects etc. Conversely, any responsibility you can take of his shoulders is a direct widening of the choke, meaning more can get done.

Answer 2

As an overly-controlling "tech guy" with too much on their hands...

Currently, your bus factor is 1. This is just very bad. From the tech perspective, unfortunately, it makes it a terrible idea to keep pumping out features without reinforcing the existing structure first. Ideally,

1. Have the Tech Guy do the refactoring/support, assign one more person to them to work together and learn from them. No other responsibilities, just this - tech support, bugfixing, learning how the system works. Make it so that the Tech Guy can't fix some of the bugs themselves, they should be explaining instead and fixing them "with other guy's hands" so to say. Hugely inefficient at first and "I'd do it myself 10x faster" but needs to be done.
2. Identify Sales Guy's bottlenecks - you seem to be bit lacking their side of the story, at least the way you told it: something hinted at by other commenters as well.
3. Do not let the Business Guy micromanage the team. People read about Agile and so on and think that posting 10 tasks (especially if they're like "add X button to Y form" instead of "customers want to be able to do Z") to some sort of a tracker is going to fix their issues. Absolutely. Not.
4. Have the actual engineers have a say in the roadmap/milestone planning/deadlines. Push back on customer demands. They always want more, soon, and sales/business people are quick to agree on technically infeasible terms as long as it means "growth".
5. Crucially, identify what said "growth" means to your company. I can't stress this enough (never mind it being the 5th point on the list). If you are making niche software, it is expected to grow to be slow and also expected for you to be able to take your time dealing with internal issues. Who could be your new customers? What will you be offering to them? Can you integrate it in your existing platform and how hard would it be?

Overall - yes, you are exactly right they need to slow down. Also, sorry to be blunt, but whatever management is only concerned by some KPI is a bad management. Indeed, freezing the spec and letting people work on it for a while would probably be the best. Indicate a milestone, take whatever Tech Guy says for the time estimation for shipping it, multiply it by 2-3 and deliver this info to customers. Also, I would really recommend compiling a newsletter instead of long calls and only have calls with customers on a single day of the week if really, really needed. If you need to call 20 customers and can only call 5 on any given Monday, make it 4 Mondays. Create some order in those interactions and better indicate to people [on both sides] what to expect.

Answer 3

Some things that come to mind:

• making sure there is buy-in from the 3 people mentioned
• tactically, Triage and Timeboxing
• for Timeboxing, both by-project, and more importantly, by-category:

I've probably re-invented the wheel here, but the following is my breakdown on the engineering side of the (hardware product) small-shop world I'm in. I'm writing from the perspective of Tech Guy. Sales Guy and Biz Guy would have their own list...

Tech Guy "timebox categories" (orthogonal to Project/Product):

(1) sales-support (2) operations (3) development (4) project management (5) organization-building

Notes on these: (1) includes some quick/dirty/MVP dev, basically whatever Sales wants. (5) includes any long term investment in your collective capabilities. (1) is always a burning priority in a small shop. (1), (2) tend to crowd out everything else. (3) tends to crowd out (5). In some places, Biz guy sees systematic (4) as a threat and sabotages it.

So if you can, get Tech Guy and Biz Guy, and crucially also Sales Guy, on board to formally and systematically block out an increased percent of time for (3-5). Do anything you can to unload (1) and (2) outside the tech team. Track hours for each category weekly. Explain that the team (ie not just Tech Guy) must rebuild both the tech, and the workflow, to not only have it function, but do so in a form that the new hires can integrate into and act independently in. While doing this, also document the process by which you work together. It's amazing what a few good process diagrams can do. (Big resistance to this initially, by the way, but well worth it once you see the light bulbs going off in people's heads). Finally, it might mean different new hires, if you have that luxury.

Hopefully all 3 key people agree with the need for a more scalable and methodical way of organizing the work ... because without their cooperation it won't happen. But be careful, foisting this kind of thing on others can be problematic. Tech Guy in particular has to completely change the way they do things, while Sales Guy will feel starved of support at first. Most importantly, you usually can't just dump your magic solution on them. And unless you are granted dictatorial powers by CEO, you also usually can't command change. Be prepared for high overhead time spent talking about it, changing plans etc.

Answer 4

Not every customer is worth it. Having been in one of these companies, some customers are worse than no customer. If a customer is taking Y hours at $X per developer hour, his cost is YX. If YX>his annual fee, he's costing you money. Put limits on how much work go into individual customers, track how much they each cost you, and convert the worse ones into time+material contracts. You'll be amazed at how many requests really aren't important when there's a dollar amount on it. Remember, all the time spent on these customers for one off work is time not spent making your software better to get the next customer. It's ok to rearrange a roadmap a bit, but things you were never planning on doing and don't benefit multiple customers cost you in money not just in salary but lost sales.

Answer 5

Tech guy holds too much information in his head. It could be shared, put in external artifacts like documentation, unit/integration tests, automated deployment, etc. Definitely, it's hard to do it to the full extent but gradual implementation would help to scale later.

You've mentioned "your business domain is complex, this is not a window cleaning shop", "each morning Business Guy writes a list of the “top 10 urgent things”" - seems like constant firefighting. Distance business guy from the tech team that he couldn't constantly ping them - hire scrum master, prioritize backlog, follow Agile ceremonies.

Does company have a broader vision and values which are known for everyone? Even it's not traditional business and underlying details are complex, still it's possible to describe value you bring in a clear and concise manner.

Eric Ries "The Lean Startup" mentions about "widespread access to the reports" so employees could review what impact was made and what brings the most value after adding new features. It would help to identify "which activities create value and which are a form of waste". Also "working in small batches quality problems can be identified much sooner" and small tasks are easier to delegate for other developers.

Answer 6

Without disagreeing with the other good answers here, perhaps they can be combined with one more view. Everyone is keen for growth, while running around like headless chickens dealing with operational issues. Perhaps to get people to start thinking about the obvious bottlenecks, you could ask two questions

• How many clients do you want in two years time?
• What does it really take to get there?

That second question needs to be answered at a technical design level, at a team capability level, and at an operational process level. Gather some basic metrics around the chokepoints and crunch the numbers.

By getting people to think about what it would mean to have 50 clients, or 100 clients, you emphasize that you want growth and success, and aren't just complaining about being busy. You also cue them to think about how a company that barely handles 20 clients needs to be significantly reshaped to realize their ambitions.