Uncategorized

A Good Architect / Team Lead

Here's my top 10 for a good architect / team leader (in no particular order):

  1. Has superb technical and communication skills that make him/her equally adept at communicating to business stakeholders and technical personnel.
  2. Owns the day-to-day execution of a team by comitting to objectives, driving decision-making, and removing obstacles.
  3. Understands the current and likely future requirements of the business and designs a solution that will allow low-cost changes along anticipated change vectors.
  4. Finds simple solutions to complex problems but, if need be, employs complex solutions such that the complexity is abstracted away from developers.
  5. Ensures key infrastructure pieces have strategic closure so that team members don't need to ingest large doses of non-business-related code.
  6. Cares about not only the technical and algorithmic aspects of technical solutions, but how these impact other team members in terms of productivity and frustration (aka inertia reduction).
  7. Listens to feedback from others and cultivates a collaborative, innovative culture because he/she understands that good ideas can come from anywhere.
  8. Holds the vision that the team is following, and can espouse that vision to others.
  9. Insulates the team from external influences when necessary.
  10. Is capable of attracting and retaining phenomenal developers because of the value they see in working with said architect/team lead.

Uncategorized

Innovation Takahashi Style

Recently I was kicking around some ideas with some work colleagues on the topic of software development and architecture (my slide deck is included below). On this topic I'm a firm believer in taking a holistic view on software development. That is, you need to focus not only on the details of the technical elements but also on both the short- and long-term business objectives of the process. This applies to the technical team as well as the BAs/managers driving the project.

More often than not there are both functional goals and business goals attached to the development exercises. The functional spec, if you have one, will elaborate on the functional goals/reqs that perhaps you have mutually agreed with your client/customers, or you may have crafted them without input from your current customers. This identifies what you are going to build but often doesn't indicate why you are doing it. Sure, "this feature solves that problem for the user" might sound like the obvious answer, but resource constraints force teams/companies to only do a limited amount of things that they could do. So then the question becomes what to prioritize, given your business' strategic objectives. These strategic goals are especially significant if the revenue of the firm is dependent on the quality and market penetration of the software you are building. After all, you need to ship before you can sell but once it hits the street [after countless iterations no doubt] your product needs to stand tall next to competitors' products. That brings me onto the topic of innovation...

Why is innovation important? Well, if you just imitate others you'd better out-execute them, or under-price them because that's all you'll have on them. This works for some companies but not for long and the margins are never great. The harder but significantly more profitable route is to out-innovate your competitors by building features that add a lot of value to the user and ARE HARD TO DO. Things that are easy and useful are going to be done by everyone - but the things that are very hard to do present a barrier to innovation that many organisations can't address even if they recognize the issue. So go looking through your Too-Hard basket and see if there are seemingly-crazy, but potentially killer ideas in that lot. You might be surprised!

Uncategorized

Evaluating an Equity Stake

Young companies often have limited cash and thus offer prospective new employees with an equity stake (often referred to as "equity participation"). Despite the recent changes to the taxation of such schemes by the Australian government employee equity stakes still seem common in technology start-ups, at least for the more senior roles. So candidates considering such roles need to evaluate the proposed, or expected equity stake in order to make a call on the value of the included equity. Below are a series of steps that I've found useful in tackling this problem.

  1. When you've reached the negotiation step of the courtship get the business model/plan from the founders. It is normal for founders to NOT want to disclose it until there is an established relationship and serious interest from both parties. However, if you reach this point and they don't offer at least the financials then you ought to be very suspicious.

  2. Look at the forecast revenue figures and compare these to other companies in the same industry. What percentage of the overall market do they represent? If it represents a large percentage do you think it's realistic given the competitors in the market? If it's very low you might want to ask why the firm thinks its' product can only capture such a small percentage. Of course a smaller piece of a bigger pie is always better than the lion's share of a small pie, unless that smaller pie is growing quickly. NB: before you get the business plan you can estimate revenue crudely by: no. of customers X revenue per customer.

  3. Look at the forecast profit margin (profit/revenue) and ask yourself if this is reasonable for the type of product/service being developed. The beauty (and curse) of digital assets is that they are easily copied leading to high margins once the R&D expense is out of the way. But you also need to consider the overall architecture because op-ex and cap-ex costs also come into play if you're storing lots of user generated content and chewing through bandwidth like it's going out of fashion, or your offering needs massive amounts of compute power which, in essence, translates to high incremental cap-ex costs making margin expansion dependent on Moore's law (cpu), Kryder's law (storage) and Nielsen's law (bandwidth).

  4. Look at the forecast profit figures and compare them to the historical profit figures of other players in the same industry. Of course future cash flows are not equivalent to past cash flows in dollar terms but you can still get an idea without needing to dive into discounted cash flow modelling if that's not your thing.

  5. If there are any other publicly-traded companies in the same space look at the P/E multiple that they are trading on. If you can't find one pick something between 13-18.

  6. Using the profit figures and forward P/E calculate a tentative valuation for the company and give the resulting figure a sanity check adjusting parameters as necessary.

  7. Consider your equity stake over time. Is it likely to grow as a result on acquired rights or allocations over time? If the company is planning additional rounds of capital raising then dilution will occur and your percentage will shrink, though the company valuation would most likely have increased.

  8. With the equity percentage estimates above you can quantify your ownership in dollar terms by multiplying the percentage with the company valuation derived above.

Apart from the valuation of the equity stake, there are of course other important things you can elicit from the business plan which will help you come to a conclusion about whether the firm is worth betting on. Basically you need to think like an investor/VC and evaluate whether you would want to put your money into the venture. The list below has some things to consider in this phase.

  • Look at the break-even time line which will be shown in a revenue vs cost graph. If it is going to take X years to turn a profit the likelihood of an exit before this time is not great so you need to plan to be around until at least this time plus a few years.

  • Look at the strengths-weaknesses-opportunities-threats (SWOT) analysis and ask yourself if it is accurate. Are there big things missing from the W/T listings? Are the S/O components overstated?

  • What are the barriers to entry? Is it easy for someone else to come along and do exactly the same thing? If so what makes you think that this offering is going to be the winner in that showdown?

  • Look at the free cash flow as this will tell you how much additional capital the company is likely to need in future rounds - which will effect your equity stake due to dilution.

Lastly, there are the gut feel things that aren't really quantifiable but none-the-less important:

  • It's common sense but worth repeating... don't do something you don't enjoy just for the money! If you are passionate about a particular area you'll find the work enjoyable and highly satisfying, but be careful - passion can blind you from reality and cloud your judgement on the business case.

  • If you don't have faith in the management team then move on to other opportunities. The management team of a speculative venture is responsible for both strategy and execution, as well as raising additional rounds of capital. If management fail on any of these 3 items the business is doomed.

So all-in-all it's just like playing the stock market - you'll lose some and win some. You just need to pick more winners than losers because each investment could be 5 years of your working life. Also note that positive things can come out of failed ventures - the learning experience for one is invaluable and you'll get respect for trying from individuals who aren't completely risk-averse. I think Theodore Roosevelt said it best though:

"Far batter to dare mighty things, to win glorious triumphs even though checkered by failure, than to rank with those poor spirits who neither enjoy nor suffer much because they live in the gray twilight that knows neither victory nor defeat" .. Theodore Roosevelt (quoted on the Harvard Business School Admissions website)

Next »