Categories
decisions engineering principles leadership strategy team

Engineering Principles 2020

I believe that what we do matters, what your team does matter and what your business does matter. Below is a helpful list of ‘engineering’ principles to focus on creating an environment where we can do our best work and use our time to matter.

1 – Work on yourself, your relationships and your team

Learn every day. Listen every day and try to think every day. Have a plan to learn React Native, finish masters, start a PhD, write a blog. Life is not static and time is limited. Is there a better way to use it than to improve yourself and your relationships?

2 – Hire good people who like to make things

Look for track record of thoughtfulness, consideration, kindness and consciousness. Also, look for builders and makers. Those are the people you can rely on and enjoy building businesses with. So your interviews need to be behaviour-based – assess whether someone has opinions and isn’t afraid to argue around a whiteboard. Avoid extravert biases. In tech, especially avoid male-centric interviewing. The world is huge. Do you want your AI to be programmed by only people like you? I wouldn’t.

3 – Code always wins

Talk is cheap. Building is hard. Always favour building, releasing and learning. Adopt continuous release management and stick with it. Release small and frequently. If you can do this, you are doing better than 90% of other businesses out there. Make the release process… a process without ExCo sign offs, special tests, service shutdowns. Anything that is not automated will cause a problem. Why? Because people don’t like responsibility for something they don’t fully understand. So, avoid it. Automate it instead.

Realise that things fail all the time. That’s okay. We know that failures are inevitable. Instead of ruminating over them, aim to reduce the time lag in detecting the failure and passing bugs to the engineering team. Learn from the failure and move on.

Finally, decoupled your releases. It is much easier to control complexity if you incrementally change. So avoid big releases as they mostly fail as the tech in 2019 is too complex to be managed by control. Always rely on the tracking and monitoring data as it will help you once the logic has dried up.

4 – Every team is a startup with a common vision

Common vision is important across the business. But you also need flexibility and autonomy to move fast. Combining team autonomy with a shared vision will make your business more robust. Paradoxically you want to rely on all of your team but at the same time, you must ensure that the business can continue with people being 3 weeks on holiday without access to the internet. So what do you do? Build team autonomy. Operate in cross-functional, autonomous Agile squads. Always document well. Documenting (user sorties, test, tech strategy, plans, roadmaps) is the most efficient way to communicate accurately and succinctly. Remember team roadmaps are driven by company goals. All of these goals, as well as individual objectives and key results (OKRs), need to be visible to all.

Your user data is your gold mine. Every team needs to live security by design. Security is not only owned by the Cheif Security Officer or CTO. Security is also owned by every product manager, designer, engineer, tester. Everyone who worked on a feature is responsible for the security of user data. Get familiar with the OWASP best practices, and strive to have automated security scanning with every deployment.

5 – Continuously remove your own legacy

Be critical of yourself. Reflect on past decisions. Learn from them to try and make better decisions next time. This is not to say not to make decisions. Make them all the time but be aware of decisions which are hard to correct (any hiring decision, picking a back-office platform) against decisions which are easily fixable later (landing pages design, AdWords campaign). Every decision you make creates some legacy. Carve out 2 weeks every quarter to spend on your legacy decisions to stay on top of it in terms of cost implications and to ensure future fitness for purpose. Your business has evolved and what worked during the first 6 months might not work now.

Categories
cloud decisions design hacks leadership program security startup strategy team tools

Tech Stack for Growth

So you have launched. You figured out how to make money and you are ready to grow. A good tech stack for growth businesses is depicted in the diagram. Gowing the business usually requires more people. So your tech stack will need to expand to include user management tools. My guidance here is to make sure you figured out what’s available from Gsuite or Office 365 before adding new complexity. By the way, you should only use either Gsuite or Office 365. Never both. Remember to always avoid complexity. If you like us and many other businesses, you will have Macs and Windows. You should also understand Gsuite or Office 365 offering for user kit management before adding new tools. As a growing business, you will consider adding new customer channels. We added fairly quickly telephony and webchat and also integrations to other (non-core) services. You don’t want to build any of this unless it’s your USP which is very unlikely. Finally, remember to constantly review your technology stack to continuously remove legacy.

Categories
cloud code decisions design system

Tech Stack for Early Startup

When you start to build your business it’s often hard to work out what you need in the first 3-6months. A good start is depicted in the diagram. I think in terms of what makes teams productive so Tech Stack is divided between Ops, Product & tech and Sales & Marketing. If you operate in a highly regulated market you could have for example regulatory reporting in the compliance vertical. I constantly aim to review our technology stack to continuously remove legacy.

Categories
cloud code decisions design patterns startup strategy

Microservices dependencies are difficult to track

After building online mortgages website and backend systems (integrated with top UK banks) using microservices (Azure, NodeJS, Mongo, React) for the new project I picked a less ambitius stack while leveraging teams know how (Azure, NodeJS, MySQL, templated HTML). This article captures my thinking:

  • Fail fast – they let development teams focus on delivering features (to prove or disprove a hypothesis) rather than a complicated microservice architecture
  • It helps you to understand your requirements (UML diagrams and domain models are not perfect first time they need to evolve)
  • Microservices are complicated to develop (e.g. graceful degradation, health checks, retries) and monitor
  • Microservices dependencies are difficult to track
Categories
behaviour decisions leadership other startup

Bezos on decision making

From the letter to Amazon shareholders:

There are some subtle traps that even high-performing large organizations can fall into as a matter of course, and we’ll have to learn as an institution how to guard against them. One common pitfall for large organizations – one that hurts speed and inventiveness – is “one-size-fits-all” decision making.

Some decisions are consequential and irreversible or nearly irreversible – one-way doors – and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation. If you walk through and don’t like what you see on the other side, you can’t get back to where you were before. We can call these Type 1 decisions. But most decisions aren’t like that – they are changeable, reversible – they’re two-way doors. If you’ve made a suboptimal Type 2 decision, you don’t have to live with the consequences for that long. You can reopen the door and go back through. Type 2 decisions can and should be made quickly by high judgment individuals or small groups.

As organizations get larger, there seems to be a tendency to use the heavy-weight Type 1 decision-making process on most decisions, including many Type 2 decisions. The end result of this is slowness, unthoughtful risk aversion, failure to experiment sufficiently, and consequently diminished invention.1 We’ll have to figure out how to fight that tendency.

Categories
decisions design hacks leadership other system

What actually matters

MVP, happy path, test coverage, Devops… In practice everything is in a spectrum. Focus on building value as the primary goal.

Categories
behaviour decisions other people

Be yourself

Be yourself; because everyone else is taken. Oscar Wilde

Categories
cloud decisions other

SaaS, PaaS, IaaS, on-prem

Only a few years ago, SaaS, PaaS, IaaS options didn’t exist. If the motivation is to have scalable IT, start with SaaS options and move down the value chain. Picking on-perm or even IaaS requires a solid business justification today.

Categories
decisions design other

Azure SQL

If you end up concluding that DB as service (Azure SQL) is better compared to virtualised DB (VM with SQL Server) be prepared to tackle performance issues when migrating from on premises DB.

Categories
decisions future other

New IT

IT is responsible for all tech/dev/R&D/innovation. Right?

But what is the function of IT in a fast-moving data-driven hyper-competition market?

It is no longer mostly CTOs who hold businesses’ purse strings; by 2017 chief marketing officers will spend more on IT than their CIOs, reckons Gartner.

Customers are no longer willing just to buy the latest technology; they want to pay for specific results, for instance for sales increases achieved by using analytics software.