Categories
behaviour startup

Stay on the bus

The title comes from one of the TED talks about a photographer changing his style as a response to feedback over and over, and never accomplishing much.  The talk’s theory is called the Helsinki bus stop theory as it was told in the context of going back and picking up another bus from the (Helsinki) bus stop and not reaching the destination.

Often investors prefer startups to change “buses” fast so the testable surface area of ideas increases. But as in the TED talk enduring the feedback and building on could be the best way.

 

Categories
behaviour book climate

Deep Adaptation: A Map for Navigating Climate Tragedy

This scientific paper is super depressing as it outlines arguments which sum up to the fact that we are facing inevitable collapse, probable catastrophe and possible extinction due to global warming. I think there is no point getting depressed but we need to acknowledge the facts of global warming and start addressing the inevitable adaptations our society will have to go through. No point discussing any more. We need to start acting now. 

 

Categories
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.

Categories
behaviour future leadership strategy

Beginning of year 2019 post

The holiday period is always a good time to reflect on the year gone by, and to turn our minds to the future.
 
2018

We started in March 2018 with an idea that we had for a while: making debtor experience best it can be while making the collections process as efficient as it can be. 

I won’t dwell too much on 2018, but what another fantastic year for our business! We developed the product and accompanying service and started executing go-to-market, hired the the team and secured a business incubator backing.

We also learnt a lot on the way. However the key lesson for us would be that hyperrealism is a friend.

  • Assuming the product will resonate with the market (if untested) will most likely be proven wrong. On reflection this is obvious.
  • Product-market fit takes time. Assume you are wrong, so test. Don’t pitch to customers. Proof is to have a meaningful commitment: signed order, intro to a decision maker.
  • Message-market fit will come from talking to customers.
  • Deep analytical understanding is only possible with sufficient data being available.
  • Create your data by talking to customers, partners and competitors. Don’t pitch, think of uncomfortable question to ask, listen to answers and try to disprove your own world view.
  • Once you stop hearing new info you probably know enough to develop testable product hypothesis.
  • Product team needs to lave products (not just in your own domain). Actually better to have broader product experience than domain experience.
  • New product requires new thinking applied to proven product design. No need to invent unessential elements of your product. Use best practice for sign up, activation, integrations, security.

2019

Taking leanings from 2018, we are looking at 2019 with clear focus on go-to-market, building a strong team and serving our customers.  

Categories
chatbots conversational UX / AI

Chatbots for Debt Collection

There is a growing expectation that chatbots can be used for debt collection. The obvious low hanging fruit is for a chatbot to:

  • Answer questions about the debt
  • Qualify a customer through a set of gated interviews:
    • General questions
    • KYC
    • Debt specific questions
    • Specialist questions eg payment plans
    • Process payments (link to Apple or Google Pay on mobile)
    • Organise phone call
    • Gather feedback
  • Provide the qualified information to the customer
  • Provide a status of outstanding balance
  • Confirm next steps

The benefits are:

  • Better governance and compliance
  • More comprehensive audit trail
  • Increase objectivity and consistency
  • Ensure strong equality
  • Reduce cost
  • Scalable parallel interviews
  • Offer 24/7 service when it suits the customer
  • Retain knowledge, especially for specialist subjects
  • Better customer experience
  • Reduce complaints and litigation

Interestingly, the knowledge assets produced for the ecosystem of chatbots involved could become a game changer in the in the debt collection industry, and for Call Centre Operations teams internal fulfilment processes.

The conversational UX could be extended to include advice for customers such as how to manage a budget, find work…

Categories
blockchain crypto future payments security startup trading venture capital

The seven deadly paradoxes of cryptoassets

On one hand cryptoassets are losing value but there are still fat margins to be made by providing trading infrastructure (eg exchanges) for people looking for a bit of fun.

The author of this article is taking a longer term view about crypto: Will people in 2030 buy goods, get mortgages or hold their pension pots in bitcoin, ethereum or ripple rather than central bank issued currencies? I doubt it.  Existing private cryptocurrencies do not seriously threaten traditional monies because they are afflicted by multiple internal contradictions. They are hard to scale, are expensive to store, cumbersome to maintain, tricky for holders to liquidate, almost worthless in theory, and boxed in by their anonymity. And if newer cryptocurrencies ever emerge to solve these problems, that’s additional downside news for the value of existing ones.

Categories
behaviour people

The Problem With Feedback

The author of the Atlantic article argues: The proliferation of ratings systems doesn’t necessarily produce a better restaurant or hotel experience. Instead, it homogenizes the offerings, as people all go to the same top-rated establishments. Those places garner ever more reviews, bouncing them even farther up the list of results. Rather than a quality check, feedback here becomes a means to bland sameness.

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
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.
http://www.black.design

Categories
code hacks

SQL query execution order

Since going back from Mongo/NoSQL to MySQL, I keep rediscovering the execution order of SQL query.  

Inside Microsoft® SQL Server™ 2005 T-SQL Querying

(8)  SELECT (9) DISTINCT (11) TOP <top_specification> <select_list>
(1)  FROM <left_table>
(3)       <join_type> JOIN <right_table>
(2)       ON <join_condition>
(4)  WHERE <where_condition>
(5)  GROUP BY <group_by_list>
(6)  WITH {CUBE | ROLLUP}
(7)  HAVING <having_condition>
(10) ORDER BY <order_by_list>

The first noticeable aspect of SQL that is different than other programming languages is the order in which the code is processed. In most programming languages, the code is processed in the order in which it is written. In SQL, the first clause that is processed is the FROM clause, while the SELECT clause, which appears first, is processed almost last.

Each step generates a virtual table that is used as the input to the following step. These virtual tables are not available to the caller (client application or outer query). Only the table generated by the final step is returned to the caller. If a certain clause is not specified in a query, the corresponding step is simply skipped.

Brief Description of Logical Query Processing Phases

Don’t worry too much if the description of the steps doesn’t seem to make much sense for now. These are provided as a reference. Sections that come after the scenario example will cover the steps in much more detail.

  1. FROM: A Cartesian product (cross join) is performed between the first two tables in the FROM clause, and as a result, virtual table VT1 is generated.
  2. ON: The ON filter is applied to VT1. Only rows for which the <join_condition> is TRUE are inserted to VT2.
  3. OUTER (join): If an OUTER JOIN is specified (as opposed to a CROSS JOIN or an INNER JOIN), rows from the preserved table or tables for which a match was not found are added to the rows from VT2 as outer rows, generating VT3. If more than two tables appear in the FROM clause, steps 1 through 3 are applied repeatedly between the result of the last join and the next table in the FROM clause until all tables are processed.
  4. WHERE: The WHERE filter is applied to VT3. Only rows for which the <where_condition> is TRUE are inserted to VT4.
  5. GROUP BY: The rows from VT4 are arranged in groups based on the column list specified in the GROUP BY clause. VT5 is generated.
  6. CUBE | ROLLUP: Supergroups (groups of groups) are added to the rows from VT5, generating VT6.
  7. HAVING: The HAVING filter is applied to VT6. Only groups for which the <having_condition> is TRUE are inserted to VT7.
  8. SELECT: The SELECT list is processed, generating VT8.
  9. DISTINCT: Duplicate rows are removed from VT8. VT9 is generated.
  10. ORDER BY: The rows from VT9 are sorted according to the column list specified in the ORDER BY clause. A cursor is generated (VC10).
  11. TOP: The specified number or percentage of rows is selected from the beginning of VC10. Table VT11 is generated and returned to the caller.

Therefore, (INNER JOIN) ON will filter the data (the data count of VT will be reduced here itself) before applying WHERE clause. The subsequent join conditions will be executed with filtered data which improves performance. After that only the WHERE condition will apply filter conditions.

(Applying conditional statements in ON / WHERE will not make much difference in few cases. This depends how many tables you have joined and number of rows available in each join tables)