Tech Guidance for Non-Technical Founders

Yesterday I wrote about the need to establish a meeting rhythm. I chose this topic because most of the founders I work with resist this. Why do they resist management techniques such as this? I think it could be part personality and part cultural. Personality because people who have big ideas often don't like the constraints of well-defined systems. I don't mean hereditary culture, but "startup culture". I think there is a common belief that startups don't need to pay attention to traditional...

In Scaling Up, the author Verne Harnish outlines the importance of establishing a rhythm for your company's meetings. In my experience, this is challenging for founders, especially those running bootstrapped startups. This is mainly due to not having enough time (due to usually having a day job) or not understanding the benefits of regular meetings. The point of establishing a rhythm for your meetings is that it creates a pulse for your business. A sense of regularity that helps your staff...

Writing well is an essential skill for anyone working on a software development team. While making use of video, audio, images are all important, writing is the core and the glue that ties these together. We write in chat, when creating user stories or raising bugs, when adding copy to your application, and when producing reference materials for customers. Writing well means communicating effectively. When you write well: You make asynchronous work more effective You reduce wasting of your...

Yesterday I wrote about the possibility of inadvertently receiving large bills from your Cloud provider. Here are four ways you can avoid this: 1. Budgets All major Cloud providers have functionality around budgets. This covers monitoring spend, alerting, and in some cases capping. In all cases you should set up budget alerts. These allow you to be notified if your spend hits a certain threshold in a given period. For example, you may configure them to alert you when 80% of your expected...

Rebooting my daily mailing practice after life got in the way! -- When you host your application in the Cloud (say AWS or Azure) you have access to virtually infinite scale. This means, without much preparation, you could run your application on 100 or 10,000 servers and the only limitation is cost. Similarly, Cloud providers have various "serverless" computing options, which, loosely speaking, is where you can perform logical operations on data and only worry about writing the functions. The...

There was a bug in your application's code. An attacker uses it to get the database credentials and extracts the data from every table. The user table contain passwords, emails and names. Other tables contain DOB, addresses, and tax numbers. The impact of this data breach depends a lot on your application's approach to data security. Data security (the confidence that your data is safe from unauthorised viewers and remains uncorrupted) requires a layered approach. This spans from physical...

I often see recommendations to non-technical founders that an MVP is built with a no-code tool. These can be suitable if your particular idea would genuinely benefit from what these offer, but it’s important to realise that these tools are rarely simple, despite being sold as such. They each have their own learning curve and usually require quite a bit of research to accomplish more advanced tasks. When you’re just getting started with your idea, it makes a lot of sense to try to build...

Lately I've been trialling some new developers, which I do periodically. Every time I do, it makes me consider what's really important when assessing whether someone will be a good fit for a project. Obviously experience with the technical stack used on the project is important, as is overall commercial experience. Those and ability to communicate effectively are what I'd generally use to make a decision. More recently I've incorporated attention to detail in the assessment. I define...

Something that can be challenging when describing complex tasks to developers is knowing whether they really understand all the requirements. To some degree, this is just part of normal human interaction and knowledge transfer but there are some ways you can make it less painful. Focus on the outcomeWhen writing up a task, define the conditions and behaviours you will be testing for.In other words, rather than trying to describe the whole solution, you're defining the 'acceptance...