minware

If YCombinator jumped off a bridge, would you? It’s shocking how many people make life-changing HR decisions based on what’s happening in Silicon Valley. My previous start-up Collage successfully bootstrapped over a decade without an office. Remote work is still better for many companies, especially those with a strong culture who care about efficiency and aren’t backed by venture capital. Before ditching remote work, it’s important to look beyond obvious factors like the cost of rent and closer communication. Other benefits like long-term talent acquisition are more subtle, but can have a huge impact. Read more about the less obvious things to consider before recalling your team to the office, and when it really is time to force people back on site.

When I sold Collage and first took over as CTO at the parent company, the CEO told me: “Project X was supposed to take three months. We’ve been working on it for a year and I don't know why.” For many CEOs, software engineering is a black box. Yet, software project failures are rampant. Big companies may be able to absorb these failures, but they can mean the end of the line for a team with limited resources. I hear different versions of this story every day, and they share one thing in common: bad planning. **It doesn’t have to be this way.** By instituting a few key practices and metrics, business leaders can dramatically decrease the risk of software project failures without micromanaging or getting into the weeds on technical details. In this article, I cover what every CEO should know about software planning, along with key misconceptions and why “agile” fails to keep projects on track.

It may seem crazy for a team with limited resources to fix all their bugs before working on new features, but it can speed up feature development. Bugs are much harder to fix the longer they wait. Deferring them is like taking out a payday loan to repay the last. I have adopted the practice of “Fix all bugs within one sprint or mark them as won’t fix.” It was painful at first, but now I wouldn’t want to work any other way. All the headaches I experienced balancing priorities and planning work with a bug backlog have gone away, and sometimes it’s easy to forget what it was like before. Without keeping a bug backlog: 1) Roadmap planning becomes easier with fewer interruptions and not having to allocate time for backlogged bugs. 2) You stop having to make daily decisions about when to fix each bug. 3) You don’t have to worry about customer emergencies caused by bugs, which reduces stress for everyone and improves the customer experience. 4) Ultimately, the rate of new bugs goes down as developers invest in better test automation. This article talks about how to make “fix all bugs” a reality with practical strategies for classifying, prioritizing, and tracking bugs using an SLA to minimize their total cost and increase feature velocity.

The $86m company I founded (Collage) went bankrupt after about a year under professional management. The thing is, those same managers were improving things at the buyer before they acquired us! My take on "founder mode" is this: hiring replaceable managers will drive you to the middle. If you're operating very well, it will make you worse. If you're operating poorly, it will make you better. A lot of founders are great builders but terrible managers. Once they get some traction, things become a total clown show (which I've seen first hand). Private equity makes money for a reason. That reason is cleaning up the messes left by inexperienced founders. For every founder like Brian Chesky (AirBnB) who can successfully run a company in the image of Steve Jobs, there are 10 others who think they can, but would really be better off bringing in professional managers.

I hear a lot of bad arguments for not doing good sprint planning. “My team is too small.” “I’ve got bigger problems to worry about.” “Software estimation is impossible.” “Good metrics take a lot of time.” Don’t be fooled – the reality is that you can and should break down work into small, estimatable tasks even if the broader project scope is ambiguous. You should also track how well you’re doing with metrics that go beyond basic sprint reports, which have major blind spots. Not doing so wastes an order of magnitude more time than the cost of planning and measurement. And yes, even if you’re a new/small team, this applies to you. If you’re pre-product-market-fit and your chances of failure are high, you should try to fail as efficiently as possible so you can live to fight another day. At minware, I’ve seen customers with very small companies (<10 engineers) doing a lot of advanced sprint metrics that go beyond canned Jira reports. These teams are killing it. Whether you’re in a garage or at a big company, you should strongly consider using advanced sprint metrics with your team. Read more about what these metrics are and how to compute them with the tools you already have here.

*CEOs*: don't put your engineers in this position. I've been in it and it sucks. Track unnecessary fire drills and hold people accountable -- it's easier than you might think! https://lnkd.in/d5exu_rs

We’ve all seen someone drowning in urgent requests. Whenever a new task comes in, they stop and work on it – hoping to finish before the next interruption. Everyone knows they’re overloaded, so they keep following up on Slack: “Is it done yet? This is really important, it’s for XYZ!” So much time is wasted communicating and context switching that barely any is left for the work itself, which further exacerbates the problem. This overhead that would disappear if you just worked on the same tasks one-at-a-time in order is your *interruption tax*. While it’s easy to see this happening first hand, actually *measuring* it so you can track the severity of the problem across an organization is tricky. Read more here about how to calculate the cost of interruptions (on your own or with minware), and systematically manage prioritization as you scale your engineering organization: https://lnkd.in/eHm7dT74

Why minimal engineering? The vast majority of companies either can’t raise VC, or are larger and have passed the hyper-growth phase. Yet, all people want to talk about is this hyper-growth fantasy and not the hardcore discipline you need to thrive with limited resources. I started minimal engineering to give a voice to the rest of us building software without a blank check. It is possible, and you can beat competitors who have 100x the budget. I’ve lived it first-hand bootstrapping Collage to $86m revenue with 15 engineers, and plan to share everything I learned along the way. Join the minimal engineering movement today.

This might be an unpopular opinion, but software engineering is wasteful and undisciplined compared to other industries like security. Google’s CEO can have confidence in their low-level firewall settings, but what about their day-to-day engineering practices? The security industry has solved this best-practice control problem, but engineering hasn’t caught on yet. This creates a huge opportunity for companies who figure it out to run circles around their competitors * Why is security more disciplined? * Well, security teams can’t afford otherwise. The cost of an incident is huge, and it only takes a few small mistakes to let in a hacker. In software engineering, mistakes lead to death by a thousand cuts. When you lose market share, it’s impossible to trace it back to one source, which makes individual mistakes easier to hide and downplay. * How do security teams prevent mistakes? * Or, the better question is: how can Google’s CEO actually be confident in their low-level firewall settings? The answer is hierarchical recurring controls. This is a fancy way of saying that they have a process for changing firewall rules. Then, they audit that process to make sure it is running effectively, audit the audit, audit that audit, and so on. Eventually, there is a top-level leadership review of the entire security program. This is how you manage important details at scale. * What should software engineering teams do? * Things really turned a corner at my former company Collage when we introduced a centralized and hierarchical recurring control structure for engineering. It doesn’t have to be anything fancy (ours was a spreadsheet), but you essentially need a list of review activities with frequencies, and another list with instances of those activities so you can see when they should happen and view the results. Read the rest including a list of suggested review activities for software companies here: https://lnkd.in/evuduW-9

Managing engineers based on what people say doesn’t cut it anymore in the era of tighter budgets. People are insanely biased, so you need data to make good decisions. If you rely only on conversations and surveys, you’re going to have these major efficiency problems: (1) You’ll put a lot of effort in the wrong places We did a test at Collage.com where we surveyed the customer service team. We asked how many times they personally experienced a severe bug in the past week that corrupted customer data. The catch is that we knew this bug had only happened once based on system logs. The results? The combined surveys indicated that the issue had happened OVER 50 TIMES! Availability bias is super powerful and everyone is susceptible (including leaders), so you need data to know the real impact of issues associated with strong emotions. (2) You won’t put effort where it’s badly needed Bias is even more dangerous when it runs the other way and people normalize major inefficiencies. We had another bug at Collage.com where the shopping cart wouldn’t scroll and it was impossible to check out with multiple items. The way customers describe this when they call support though, it sounds like “user error” or “browser issues.” This went on for days and days before someone actually found the bug while testing, even though a bunch of customers had called us about it. We had become so used to dealing with similar-sounding non-issues that we didn’t think anything of these warning signs. As a manager, you may be shocked to see what people endure every day without thinking to speak up when you dig into the data. (3) You’ll create a highly political organization Not having data doesn’t prevent people from forming strong opinions. At best, engineers will waste a ton of time arguing about things. At worst, the loudest voice will be the wrong one, and your quieter, more talented engineers will quit. -------- WHAT TO DO INSTEAD It’s still important to listen to people, and the fact that someone feels bad about something is a problem itself. But, people are very bad at estimating the MAGNITUDE of problems. In 2024, engineering teams have to use data if they want to survive. It’s fine to use qualitative feedback as a starting point, but you need to measure how often the things you hear about are actually happening. Exploring that data to see what people aren’t telling you is also important, either because they’ve normalized inefficiency or can’t see the big picture from their perspective. It’s critical to have full observability of your development systems, including Jira, GitHub, CI/CD, etc. This lets you see things bottom-up, not just top-down. Ticket data can provide some context, but most of the information about tech debt, slow processes, poor developer experience, etc. requires looking across lower-level metrics and matching sequences of events across different systems. Start small, start big, but start now before it's too late.