behaviour patterns people team work

Location, location, location of the Engineering team

Where’s the team? Is it in house? Why is it remote? People are interested. They have a right to know. However, I am always interested to find out what’s behind the question.

My data sample is small and built from my experience as CTO and working on consulting projects. So I am biased. Nevertheless, I think once you find more about the person asking the question you can correlate their view fairly accurately to the perceived right answer.

If the person is a recruiter or a talent manager, commonly the view is that in house creates better team dynamics and creates more hiring work which people with local hiring experience are more comfortable with.

If the person is from a finance department, the outcome is diagonally different. The cost, time to market and scale play a big part as to what good looks like.

Is the person is a CEO or an investor, there is no given right answer usually as there is awareness that not one answer fits all situations. And usually the strategic decision about the team make up is taken considering many variables but primarily where can I hire the best people to grow my business fast.

Finally, if the person is an engineer, she or he won’t care. Why? Because engineers want to work with the best engineers, making location irrelevant.

Having managed teams of 2 people to 60+, I think what’s important is how one is organised, what processes are followed and how well work is documented and tracked.

Usually default opinion backing the in house teams option is hidden behind poor communication, undeveloped technology strategy, immature operating model and incomplete documentation (stories, roadmap, tests). Lack of any of above is not a good enough reason to pick any option. Don’t miss on top talent for being lazy.

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
design hacks patterns short startup tools

Early stage startup design resources

The Black Design resources let you conduct a meaningful user observation, engage in product design, and communicate value of your business.

blockchain other patterns

Data Exchange: A shared ledger

A shared ledger technology allowing any participant in the business network to see THE system of record (ledger).

Solution – a shared, replicated, permissioned ledger. Consensus, provenance, immutability, finality.

New data exchange patter emerges: structured data (DB) -> encryption -> structured data (shared ledger DB).

other patterns

Data Exchange: Business Networks, Markets & Wealth

Business Networks benefit from connectivity: connected customers, suppliers, banks, partners / cross geography & regulatory boundary. Wealth is generated by the flow of goods & services across business network. Markets are central to this process: public (fruit market, car auction), or private (supply chain financing, bonds)

Most common organisational data exchange pattern: structured data (DB) -> unstructured (file, message) -> network -> unstructured (file, message) -> structured data (DB).

Problem - Difficult to monitor asset ownership and transfers in a trusted  business network
. Inefficient, expensive, vulnerable.

code design other patterns

Cloud patterns

A lot can be said about designing for cloud-first. Async as default, for example. Chatty DB issues of systems designed with an implicit view that data is instantly available (on-prem DB, for example). However cloud DB suffer from latency causing issues.
A good starting point is to to recognise that different physics is at play in the cloud.

code design other patterns

Microservices pattern

A lot of developers talk about microservices. Microservices at an outset appear anti-agile as separation has to be tackled early on which is not easy as most of the time deeper understanding is required in order to decide how to brake up components. Build MVP and decompose when you learn….

cloud code other patterns

Big Data anti-pattern

Installations of Hadoop with Gb data feeds that would be faster processed on a laptop.