minware

A disagreement about employee compensation almost killed the sale of Collage.com to private equity back in 2021. A top employee wanted a raise, but the buyer was concerned because he was already being paid above the 90th percentile for his job role. The problem was that he was a 99th percentile employee, not a 90th percentile employee. We knew that he could get a job at Google for the salary he was requesting, but the buyer had no good way of verifying our claims. This problem is pervasive at the top end of the talent market because it’s difficult for most companies to tell the difference between great people and the very best. As a result, information asymmetry creates a lemon market where the top engineers are the most underpaid. This article explains why you should hire the most expensive engineers you find (they are the best bargain, even for small/bootstrapped companies!), and how to pull it off without ending up with a lemon.

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