There are a few things in life I consider it ok to be faith based. At the workplace, one is diversity & inclusion. I do not need proof or data that workplace diversity is good. It just is. Having different experiences and backgrounds lends itself to a workplace which is more interesting, more balanced, and lends itself to a greater diversity of ideas. It is more reflective of the diversity of your customers. It will result in better business outcomes without seeking it.
I recently had a discussion with my peers about engineering productivity and metrics around our fiscal allocations. some concerns about the rate at which certain software defects were being resolved. There was one concern: defects labeled P3/P4 (lower priority) were being closed at a slower and slower rate over time.
The realization I had was the system was performing exactly as intended. We had inspection points in the system: the inspections were about delivering value to the customers (product roadmap) and ensuring quality attributes (availability/performance/security/product quality) were where we expected it to be. Product quality was assessed by the number…
A project is started. Goals are set. Timelines are established. And then you start tracking to those timelines, and you report out using your friendly Project Manager, and as releases happen, the product managers are collecting feedback and the customer support channel is telling you how customers are liking it.
And there you are, the engineer. With no line of sight to what is actually going on with the customer.
You remember the game of telephone? You whisper something to the person sitting next to you, who whispers what they have heard to the next person.. and when the circle…
A growth mindset means that failure is acceptable: you need to have set clear outcomes and have learnt from it, and make it safe to fail. But failure also means you have learnt from it, and are now able to use that learning in useful and interesting ways.
The best engineers I have known and admired have had two traits: Curiosity and Camaraderie. Curiosity because curious engineers have a growth mindset and find better ways of doing things. Camaraderie because being a team player rubs off this sensibility of the people around you, and helps elevate the entire team.
Here is what I have learnt about hiring:
A Players hire A+ players because they want to learn from the best
B Players hire B players because they identify with them
C players hire D players because they want to make sure they are not at the bottom.
You know that interview in which the interviewer asks an impossibly difficult question and settles back with a smug look? That is your C player ensuring that A players do not make it into the company.
The most important job for your A players is hiring. This is how you set the…
You know what some architects like to do? Build abstraction layers. Because it makes for pretty pictures. And it solves business problems where they are thinking about ‘just in case’. Very often, It is better to think about it in terms of ‘just in time’ rather than ‘just in case’.
An example of this is a brain melting conversation I once had, where there was a proposal to build an abstraction layer to abstract away services from OUR CLOUD PROVIDER. ‘What if we decide to move to a different cloud provider? We will be screwed’ was the rationale.
You need data. An organization flies blind without data and regular inspections of data.
When you set a goal — your target state, for example — how do you know you have accomplished it? By writing clear metrics that establish success and failure. Similarly, if you do quarterly planning, you need to ensure that you have written down what your success metrics are. Without writing this down, and having regular inspections of these metrics, you do not know if you are succeeding or have succeeded.
I like to have a single metrics review every other week where all data is…
It is surprising how often leaders focus on cost and ignore the value side of the equation.
An example is the use of platform services in a cloud provider. It costs money to use any of the managed services (think about RDS vs self hosted Databases in AWS, as an example). The opposition to managed services is surprising. ‘It will cost us $XX more than what we could get with EC2!’
What is missing in this picture is the value calculus. You cannot look at just the cost of something: you have to look at the value to cost ratio…
So you have had a conversation with the CEO, set your strategic objectives, and defined your investment buckets. Great. What should you have your teams work on, and where should you rely on others (consultants, contractors etc?). A CTO must always have a clear picture of what is core and what is context.
Core is defined as being part of the secret sauce of the company. Anything that is a competitive advantage or the key value add in the company is core. Anything that allows us to delight customers or move faster is core.
Contextual work is work that is…
Your job as your CTO means working with your counterparts — legal, finance, marketing and others. A key partner is the finance team. You have to understand your budget and how it maps to your target state
I use a standard framework that has worked well for me which has 3 components: Budgets are distributed into 3 buckets: Product Roadmap, Sustaining Engineering and Tech Modernization
Product Roadmap refers to everything that that is feature oriented and part of the product roadmap for customers (and internal partners)
Sustaining work refers to the work required to support existing features. …
@_siddharth_ram; CTO @Inflection