In a small & fast engineering team, it’s challenging to quantify work being done. There’s so much to do, and it’s difficult to categorize. How can you determine your capacity for addressing your strategic roadmap when stakeholders ask about it?
Software building is a team activity, and QA is an indispensable stakeholder on a well-functioning team.
Moments worthy of victory laps come from stories which have a beginning, middle, and end. If you’re not actively communicating these stories to a team, eventually startup-era victory laps fade into memory.
If you don’t invest in engineering leadership early you’re burning your salary budget. Once it’s time for process, you need someone who empowers your engineers and helps them operate safely rather than imposing rules that grind your releases to a halt.
A moment of conceptual breathing room by putting forward a well-articulated, divergent view could save a ton of resources later.
When you’re building a software product, time always feels like your enemy. Co-opting an existing feature for a new use can feel extremely clever, like you’ve sidestepped a ton of work. But it doesn’t scale, it adds friction, and it adds danger.
Shipping new features feels like it’s increasing the “moat” around your product because just look at all the time and effort it took. There’s just one problem: Features aren’t a moat.
Offering community managers a forum to build a community is like giving a project manager a kanban board. Yes, they can make it work. But is there really a “kanban market”?
Designing software that doesn’t account for human mental models is unethical. It gaslights people into thinking they’re incapable, and the domino effects of that are incalculable.
