I had a great chat with Lamak, who works at one of the startups in Karachi called Bazaar Tech. We discussed several interesting topics including team structures, full stack development, performance reviews and more! Thanks Lamak for taking time out for this episode of EngineeringLeadershipPakistan.

I had a great chat with Lamak, who works at one of the startups in Karachi called Bazaar Tech. We discussed several interesting topics including team structures, full stack development, performance reviews and more! Thanks Lamak for taking time out for this episode of EngineeringLeadershipPakistan.

I had a great chat with Asadullah about his time in Airlift where he was an engineering manager leading a specific team. We talked about several management related topics, from the values at Airlift, life there as an engineering leader,  performance management, hiring, engineering productivity and more! 

You can also watch this on the KarachiWalaDeveloper Youtube channel.

I had a great chat with Asadullah about his time in Airlift where he was an engineering manager leading a specific team. We talked about several management related topics, from the values at Airlift, life there as an engineering leader,  performance management, hiring, engineering productivity and more! 

You can also watch this on the KarachiWalaDeveloper Youtube channel.

This is the first episode of the all new series where I will be interviewing Engineering Leaders in Pakistan. We will be talking about leadership topics like CTO roles, hiring, performance reviews, feedback and more. In this episode we have Hunain Kapadia from Smart Benefits sharing about this experience building the some awesome tools in the insurance space.

This is the first episode of the all new series where I will be interviewing Engineering Leaders in Pakistan. We will be talking about leadership topics like CTO roles, hiring, performance reviews, feedback and more. In this episode we have Hunain Kapadia from Smart Benefits sharing about this experience building the some awesome tools in the insurance space.

Software Engineers require instructions in order to build apps and tools. And most of us don't know what these instructions should look like. One of the ways these instructions can be shared is in the form of user stories, and it's not just about writing a bunch of text, but comprehensive check list of how this should be structured so the right information can be given to the builder. Ofcourse its a two way effort Product and Engineering need to work closely to build up such requirements so they make sense from a functionality perspective, and a technical perspective.

This session is based on the article linked below:

https://martinfowler.com/articles/product-backlog-building-canvas.html

Software Engineers require instructions in order to build apps and tools. And most of us don't know what these instructions should look like. One of the ways these instructions can be shared is in the form of user stories, and it's not just about writing a bunch of text, but comprehensive check list of how this should be structured so the right information can be given to the builder. Ofcourse its a two way effort Product and Engineering need to work closely to build up such requirements so they make sense from a functionality perspective, and a technical perspective.

This session is based on the article linked below:

https://martinfowler.com/articles/product-backlog-building-canvas.html

Google, or any of the FAANG companies for that matter, are an awesome place to work. When I started by bachelors - I was thinking of graduating and then getting a job there, or build a pathway to a job there. However by the time I graduated, my mind set had changed. In this episode I explore my thoughts and reasoning on what changed my mind and why I havnt applied since.

Google, or any of the FAANG companies for that matter, are an awesome place to work. When I started by bachelors - I was thinking of graduating and then getting a job there, or build a pathway to a job there. However by the time I graduated, my mind set had changed. In this episode I explore my thoughts and reasoning on what changed my mind and why I havnt applied since.

With startups going bust left right and center, high inflation and a global recession - are startups still the right choice to be at? In this episode I talk about the difference between the companies treating engineering teams as a profit center vs a cost center, to show why startup engineering teams as usually a better choice even if there is a slightly higher risk being there.

With startups going bust left right and center, high inflation and a global recession - are startups still the right choice to be at? In this episode I talk about the difference between the companies treating engineering teams as a profit center vs a cost center, to show why startup engineering teams as usually a better choice even if there is a slightly higher risk being there.

In this episode I break down a good engineering culture using two different culture tests from the web. We take a deep dive into the technical side of the culture first, followed by the work and management culture. How does your company score - what is the one thing you would change in your company to make it a better experience?

In this episode I break down a good engineering culture using two different culture tests from the web. We take a deep dive into the technical side of the culture first, followed by the work and management culture. How does your company score - what is the one thing you would change in your company to make it a better experience?

Javascript is one of my favourite languages out there. Im not sure if it just the familiarity with the language (have been using it since age 10) or the fast pace of change in the language space or the fact its being used on space craft - I think its a useful skill to have for anyone working in the software industry. Check out my rant on what makes JS so awesome according to me!

Javascript is one of my favourite languages out there. Im not sure if it just the familiarity with the language (have been using it since age 10) or the fast pace of change in the language space or the fact its being used on space craft - I think its a useful skill to have for anyone working in the software industry. Check out my rant on what makes JS so awesome according to me!

As programmers we work hard all day to ensure we build the best products in the best technical way possible, and if that work isn't shipped to customers right away, we are unable to generate any value of it for the company / product. DevOps plays a critical role in our organisations today, and ensure we have an efficient production line shipping features to our customers is a part of it. In this episode we review how we can better understand and measure performance of our software delivery and what does it take to compete with the best out there.

As programmers we work hard all day to ensure we build the best products in the best technical way possible, and if that work isn't shipped to customers right away, we are unable to generate any value of it for the company / product. DevOps plays a critical role in our organisations today, and ensure we have an efficient production line shipping features to our customers is a part of it. In this episode we review how we can better understand and measure performance of our software delivery and what does it take to compete with the best out there.

While mentoring some students with technical interviews, I documented what I find to be most important qualities of a software developer or engineer. While a quick google search online will find mixed reviews, most people feel that technical skills are most important. However I feel a bit differently about this, and in this episode share the things all software engineers should focus on and how they can improve them selves if lacking.

While mentoring some students with technical interviews, I documented what I find to be most important qualities of a software developer or engineer. While a quick google search online will find mixed reviews, most people feel that technical skills are most important. However I feel a bit differently about this, and in this episode share the things all software engineers should focus on and how they can improve them selves if lacking.

The recent failure of the startup Fast got me thinking of things one needs to be aware of while considering to join a startup and things to observe while working in one. This episode covers some basics to what you can do before and after joining which should help you prepare better for the risks involved while working in a startup.

This episode was inspired by the following post: https://newsletter.pragmaticengineer.com/p/the-scoop-fast?s=r

The recent failure of the startup Fast got me thinking of things one needs to be aware of while considering to join a startup and things to observe while working in one. This episode covers some basics to what you can do before and after joining which should help you prepare better for the risks involved while working in a startup.

This episode was inspired by the following post: https://newsletter.pragmaticengineer.com/p/the-scoop-fast?s=r

Technical Due Diligence (DD) for startups is not something we think about until the time really comes in. When we get the list of questions or get asked those dreaded questions that we always knew would come to haunt us. In this episode I share about what is the process and what to expect from this, so that one can be better prepared when this happens.

Technical Due Diligence (DD) for startups is not something we think about until the time really comes in. When we get the list of questions or get asked those dreaded questions that we always knew would come to haunt us. In this episode I share about what is the process and what to expect from this, so that one can be better prepared when this happens.

T-Shaped developers are those interested in learning across a breadth of technologies ranging from frontend to backend to devops. In this episode we try to understand why would we want to diversify vs specialise and is there a better option between the two?

T-Shaped developers are those interested in learning across a breadth of technologies ranging from frontend to backend to devops. In this episode we try to understand why would we want to diversify vs specialise and is there a better option between the two?

Do you feel your team is very sluggish and not moving fast enough? Do you feel there are constant blockers which are stopping the features to get shipped? In this episode I dive into the world of engineering performance and what are some thing of the useful things you can measure, and which ones are not meant to be measured at all.

Do you feel your team is very sluggish and not moving fast enough? Do you feel there are constant blockers which are stopping the features to get shipped? In this episode I dive into the world of engineering performance and what are some thing of the useful things you can measure, and which ones are not meant to be measured at all.

You might have been reading about one of the dozen multi-million dollar investments made into startup recently. And you might be wondering how do I get a piece of that action. Most companies now offer their shares to employees through whats called an ESOP. This allows you to accrue value over time and if the company wins big - so do you! This and more in this episode.

You might have been reading about one of the dozen multi-million dollar investments made into startup recently. And you might be wondering how do I get a piece of that action. Most companies now offer their shares to employees through whats called an ESOP. This allows you to accrue value over time and if the company wins big - so do you! This and more in this episode.

PCI DSS is a security standard certification which a company requires if they have card payment integrations on their websites. However its one of those topics which sounds scary, not talked about enough and is very specific to each company. So understanding even if it is a requirement for your company becomes a pain. In this episode I share my experience going through the certification with Sastaticket and what I learnt during that.

PCI DSS is a security standard certification which a company requires if they have card payment integrations on their websites. However its one of those topics which sounds scary, not talked about enough and is very specific to each company. So understanding even if it is a requirement for your company becomes a pain. In this episode I share my experience going through the certification with Sastaticket and what I learnt during that.

In order to write faster code you need to understand (or profile) your current code and visually or numerically breakdown the pieces which need improvement. How do you do this? We use code profilers! In this episode we dive into the world of tweaking code performance and getting the most out of the hardware its running on.

In order to write faster code you need to understand (or profile) your current code and visually or numerically breakdown the pieces which need improvement. How do you do this? We use code profilers! In this episode we dive into the world of tweaking code performance and getting the most out of the hardware its running on.

Mono repos is not a new concept - but one often visited by growing organisations to help reduce the overhead of managing thoses dozens of repos in the company. Is it better? Well that depends on the company and how they work. In this episode I go through the differences and reasons why one would consider a mono repo over a multi repo.

Mono repos is not a new concept - but one often visited by growing organisations to help reduce the overhead of managing thoses dozens of repos in the company. Is it better? Well that depends on the company and how they work. In this episode I go through the differences and reasons why one would consider a mono repo over a multi repo.

Now a days even a simple CRUD based app can have a lot of moving parts - esp if deployed with something like Kubernetes. Our complex applications are growing even faster, interacting with many different libraries and handling greater and more variable loads. How do we get insight into whats really happening on the code level any more? Long gone are the days when a simple CPU usage alert would be enough to monitor most applications - today we need to monitor on different level and metrics to get a better picture of whats going on. This and more in this episode.

Now a days even a simple CRUD based app can have a lot of moving parts - esp if deployed with something like Kubernetes. Our complex applications are growing even faster, interacting with many different libraries and handling greater and more variable loads. How do we get insight into whats really happening on the code level any more? Long gone are the days when a simple CPU usage alert would be enough to monitor most applications - today we need to monitor on different level and metrics to get a better picture of whats going on. This and more in this episode.

Many thanks to the GDE program for creating this initiative! In this episode I cover my learnings from buying my first \"professional\" mic - what are some of the things you need to know and how is my experience going so far with the mic I have bought.

Many thanks to the GDE program for creating this initiative! In this episode I cover my learnings from buying my first \"professional\" mic - what are some of the things you need to know and how is my experience going so far with the mic I have bought.

Typescript is becoming one of the popular languages to use - but do we really need it? How helpful are the typings we write? What makes it stand out from Javascript? This and more in this episode covering the use of Typescript, benefits of typings, and some things to look out for.

Typescript is becoming one of the popular languages to use - but do we really need it? How helpful are the typings we write? What makes it stand out from Javascript? This and more in this episode covering the use of Typescript, benefits of typings, and some things to look out for.

As Docker and Containerisation have taken over the world - we have many different options to deploy our apps to. Within the AWS ecosystem, we have a few options from EKS, ECS and ElasticBeanstalk. While the latter might sound like an outdated option in front of EKS and ECS, it is surprisingly useful - this and more in this weeks podcast.

As Docker and Containerisation have taken over the world - we have many different options to deploy our apps to. Within the AWS ecosystem, we have a few options from EKS, ECS and ElasticBeanstalk. While the latter might sound like an outdated option in front of EKS and ECS, it is surprisingly useful - this and more in this weeks podcast.

Gone are the days when we need tech teams to setup a simple website. Now a days we simply sign up like we do for Gmail and have everything setup in no time! And it costs just a few dollars per month. No Code tech is awesome and its here to make those mundane development roles redundant. With loads of new tools out there from making simple websites to building complex data entry apps or dashboards - the ecosystem is moving fast to empower the non-technical folks out there so build tech is more accessible and it becomes easier to innovate.

Gone are the days when we need tech teams to setup a simple website. Now a days we simply sign up like we do for Gmail and have everything setup in no time! And it costs just a few dollars per month. No Code tech is awesome and its here to make those mundane development roles redundant. With loads of new tools out there from making simple websites to building complex data entry apps or dashboards - the ecosystem is moving fast to empower the non-technical folks out there so build tech is more accessible and it becomes easier to innovate.

Writing documentation is not something we think about every day - but it is something we are interacting with on a daily basis. In a world of ever changing requirements and technology, if we are not documenting our technical journey properly - we are simply rebuilding the same wheel again and again. Documentation is at the core of any product, how its build, why it's built that way. And in this podcast we cover how we write this documentation in the best way possible. This is a summary of the technical writing course linked below.

Technical Writing Docs: 

https://developers.google.com/tech-writing/one

Register for workshop here:

https://docs.google.com/forms/d/e/1FAIpQLSc26RofABVtJkF1gRE7Pm7u2RBd6NBRbdqtYVUxYD_DVKwVUg/viewform

Writing documentation is not something we think about every day - but it is something we are interacting with on a daily basis. In a world of ever changing requirements and technology, if we are not documenting our technical journey properly - we are simply rebuilding the same wheel again and again. Documentation is at the core of any product, how its build, why it's built that way. And in this podcast we cover how we write this documentation in the best way possible. This is a summary of the technical writing course linked below.

Technical Writing Docs: 

https://developers.google.com/tech-writing/one

Register for workshop here:

https://docs.google.com/forms/d/e/1FAIpQLSc26RofABVtJkF1gRE7Pm7u2RBd6NBRbdqtYVUxYD_DVKwVUg/viewform

Writing async code is important when building any application. You dont want your threads to be blocked on http calls and db look ups - esp if the language you are using is single threaded! I was surprised to find that most code written in Python is synchronous though that is now rapidly changing. Writing asynchronous code right now means using libraries like Celery which do all the work in a separate process. What is it, how do we use it and how does it work - this and more in this episode.

Writing async code is important when building any application. You dont want your threads to be blocked on http calls and db look ups - esp if the language you are using is single threaded! I was surprised to find that most code written in Python is synchronous though that is now rapidly changing. Writing asynchronous code right now means using libraries like Celery which do all the work in a separate process. What is it, how do we use it and how does it work - this and more in this episode.

In this session, I collect all the tips and tricks I have been using over the last decade and bring them together for a short 10 min checklist for making your website super fast. You can bookmark this episode and run through the points every time your website needs a boost!

In this session, I collect all the tips and tricks I have been using over the last decade and bring them together for a short 10 min checklist for making your website super fast. You can bookmark this episode and run through the points every time your website needs a boost!

If you are building a services company or an e-commerce store in Pakistan - eventually you will realize you need to accept online payments. Normally this requires a Payment Gateway - a simple service you can sign up to and integrate in a matter of minutes into your platform. But its not that easy in Pakistan as yet. What are the options? What works and what doesnt work? All this and more in this weeks podcast.

If you are building a services company or an e-commerce store in Pakistan - eventually you will realize you need to accept online payments. Normally this requires a Payment Gateway - a simple service you can sign up to and integrate in a matter of minutes into your platform. But its not that easy in Pakistan as yet. What are the options? What works and what doesnt work? All this and more in this weeks podcast.

Micro-services is the popular architecture pattern which has taken the world over by storm. The promise of small manageable applications with fast iterations and seamless efficient scaling  has attracted many developers on taking on this as a default pattern for all their apps. But we should not be too quick dismiss the handy old monolith. In this episode we take a dive into micro-services to see if they are really that amazing underneath.

Micro-services is the popular architecture pattern which has taken the world over by storm. The promise of small manageable applications with fast iterations and seamless efficient scaling  has attracted many developers on taking on this as a default pattern for all their apps. But we should not be too quick dismiss the handy old monolith. In this episode we take a dive into micro-services to see if they are really that amazing underneath.

Continuous Integration (CI) is slowly becoming one of the main pillars for software development. As our software becomes more complex we add more and more tooling around it to automate, so we can focus on whats important - writing code. CI is what runs most of that tooling and keeps it out of the way.. until we need break something and it needs our attention. It gives us the confidence to deploy, again and again so that we move faster in this rapidly changing world.

Continuous Integration (CI) is slowly becoming one of the main pillars for software development. As our software becomes more complex we add more and more tooling around it to automate, so we can focus on whats important - writing code. CI is what runs most of that tooling and keeps it out of the way.. until we need break something and it needs our attention. It gives us the confidence to deploy, again and again so that we move faster in this rapidly changing world.

Serverless architecture has become very popular over the last few years. In this episode we cover an introduction to this topic and talk about how Cloudflare Workers have implemented the serverless architecture. I share different ideas and thoughts on the ideology behind Cloudflare Workers and when they are most useful.

Serverless architecture has become very popular over the last few years. In this episode we cover an introduction to this topic and talk about how Cloudflare Workers have implemented the serverless architecture. I share different ideas and thoughts on the ideology behind Cloudflare Workers and when they are most useful.

I recently rebuilt my personal website (imars.info) using NextJS and in this episode I share my experience in building it and my thoughts on the framework and how it compares to Wordpress which is something I have been using for a long time.  _This is not sponsored content_

I recently rebuilt my personal website (imars.info) using NextJS and in this episode I share my experience in building it and my thoughts on the framework and how it compares to Wordpress which is something I have been using for a long time.  _This is not sponsored content_

AMP enables the creation of websites and ads that are consistently fast, beautiful and high-performing across devices and distribution platforms. It is an opensource toolkit which can be used for static pages as well as dynamic ones. But why do we need AMP? And how does it make our web faster? This and more in this short introduction of AMP HTML.

AMP enables the creation of websites and ads that are consistently fast, beautiful and high-performing across devices and distribution platforms. It is an opensource toolkit which can be used for static pages as well as dynamic ones. But why do we need AMP? And how does it make our web faster? This and more in this short introduction of AMP HTML.

In this final episode of the Core Web Vital series, we bring together all that we have learnt and talk about the thing that matters the most - the 3 metrics set by Google which show how good or bad our website is currently performing. Largest Contentful Paint, First Input Delay and Cumulative Layout Shift - what are they, how are they calculated and how can we improve them? Just a few of the things I will share in this episode.

In this final episode of the Core Web Vital series, we bring together all that we have learnt and talk about the thing that matters the most - the 3 metrics set by Google which show how good or bad our website is currently performing. Largest Contentful Paint, First Input Delay and Cumulative Layout Shift - what are they, how are they calculated and how can we improve them? Just a few of the things I will share in this episode.

How does a browser render an HTML page? In this episode we dive into the world of DOM, CSSOM and Critical Render Paths. We understand what makes our website loading slow and how can we remove it so it can be made faster.

How does a browser render an HTML page? In this episode we dive into the world of DOM, CSSOM and Critical Render Paths. We understand what makes our website loading slow and how can we remove it so it can be made faster.

Core Web Vitals is the new standard set by Google to measure performance of our websites. In this multi-part series we will be covering on different aspects of web performance, starting with the basics. What makes a slow website and what are some of the things we need to keep in mind when reviewing our own website. In the upcoming episodes we will discuss what makes the website slow (technically) and how Core Vitals help us make it better.

Core Web Vitals is the new standard set by Google to measure performance of our websites. In this multi-part series we will be covering on different aspects of web performance, starting with the basics. What makes a slow website and what are some of the things we need to keep in mind when reviewing our own website. In the upcoming episodes we will discuss what makes the website slow (technically) and how Core Vitals help us make it better.

In this episode I cover another very popular question I get - what kind of mobile app should I be building? With the rise of PWAs, Hybrids, Compile to Native, Flutter and native apps one does get lost in trying to figure out the best course of action. I try to explain the high level pros and cons for each and what really matter when making the decision for your mobile app.

In this episode I cover another very popular question I get - what kind of mobile app should I be building? With the rise of PWAs, Hybrids, Compile to Native, Flutter and native apps one does get lost in trying to figure out the best course of action. I try to explain the high level pros and cons for each and what really matter when making the decision for your mobile app.

In the previous episode we talked about what is the whole point of design systems, and if we need them or not. In this episode we cover a more technical perspective and discuss how do we go about building a design system from a flow perspective. We will also discuss some tools which can help us build this as well.

In the previous episode we talked about what is the whole point of design systems, and if we need them or not. In this episode we cover a more technical perspective and discuss how do we go about building a design system from a flow perspective. We will also discuss some tools which can help us build this as well.

Here is another over hyped term. Every company seems to be making one now a days? But what is a design system really? How does it help you create better frontends? Is it really more than just a component library? Will be answering this and more in this episode.

Here is another over hyped term. Every company seems to be making one now a days? But what is a design system really? How does it help you create better frontends? Is it really more than just a component library? Will be answering this and more in this episode.

Another popular question I get asked is which language is best to start off with when learning programming. Here is a quick overview of the two languages, their similarity and differences and a quick discussion on what are something of the things to think about when choosing one of them.

Another popular question I get asked is which language is best to start off with when learning programming. Here is a quick overview of the two languages, their similarity and differences and a quick discussion on what are something of the things to think about when choosing one of them.

The most controversial topic in the frontend web space - which framework is better and which one should we spent time learning? The answer is not that straight forward! - I review both of them and share my perspective on what makes each the best.

The most controversial topic in the frontend web space - which framework is better and which one should we spent time learning? The answer is not that straight forward! - I review both of them and share my perspective on what makes each the best.

One of the most frequently asked questions to me is on how does one become a GDE, and the next most popular is what is a GDE :) - so I have spent a few minutes explaining them both here!

One of the most frequently asked questions to me is on how does one become a GDE, and the next most popular is what is a GDE :) - so I have spent a few minutes explaining them both here!

Welcome to Karachi Wala Developer Podcast! In this series, I will share a little about my experience about different technologies and things related to startups. My name is Mashhood and currently I am the CTO at Sastaticket, and Google Developer Expert for Web and Angular. I have been working since I was a kid, and now with the 10+ year professional experience under my belt, I will be using this micro-podcast medium to share my thoughts on different technical things.

Welcome to Karachi Wala Developer Podcast! In this series, I will share a little about my experience about different technologies and things related to startups. My name is Mashhood and currently I am the CTO at Sastaticket, and Google Developer Expert for Web and Angular. I have been working since I was a kid, and now with the 10+ year professional experience under my belt, I will be using this micro-podcast medium to share my thoughts on different technical things.

I have seen many startups engage consultancies - esp. when they are not sure if they want to build a team in house. One of the biggest issues I usually see with that - consultancies are not designed to own any of the decision they make. For them (in most cases) it's just a project which lasts a few months or may be a year or so. This often leads to optimisations for delivery than for the product itself. Thus you can often see poor architectural decisions, spaghetti code, lack of testing and planning in general in most of these cases.

From those working in consultancy - one feels they are learning a lot by working on different \"projects\" but in reality the real learning doesn't happen when you are writing that code - it happens 2 years later when you are trying to change it and its breaking all over the place. You don’t really get to experience the product itself.

From the video, Steve Jobs says:

\"I dont think there is anything inherently evil with consulting - I think that without owning something over an extended period of time, like a few years where one has a chance to take responsibility for ones recommendations - where one has to see ones recommendations through all action stages and accumulate scar tissue for the mistakes and dust them selves off - one learns a fraction of what one can.\"

So should startups not use consultancies at all? I think they can - but the real value to a startup is only generated when you have someone in house who knows how to use that talent. If you expect to “outsource” everything - then you have no idea what you are getting in return, and usually one finds out about this towards the end of the project.

Share

I have seen many startups engage consultancies - esp. when they are not sure if they want to build a team in house. One of the biggest issues I usually see with that - consultancies are not designed to own any of the decision they make. For them (in most cases) it's just a project which lasts a few months or may be a year or so. This often leads to optimisations for delivery than for the product itself. Thus you can often see poor architectural decisions, spaghetti code, lack of testing and planning in general in most of these cases.

From those working in consultancy - one feels they are learning a lot by working on different \"projects\" but in reality the real learning doesn't happen when you are writing that code - it happens 2 years later when you are trying to change it and its breaking all over the place. You don’t really get to experience the product itself.

From the video, Steve Jobs says:

\"I dont think there is anything inherently evil with consulting - I think that without owning something over an extended period of time, like a few years where one has a chance to take responsibility for ones recommendations - where one has to see ones recommendations through all action stages and accumulate scar tissue for the mistakes and dust them selves off - one learns a fraction of what one can.\"

So should startups not use consultancies at all? I think they can - but the real value to a startup is only generated when you have someone in house who knows how to use that talent. If you expect to “outsource” everything - then you have no idea what you are getting in return, and usually one finds out about this towards the end of the project.

Share

One of my most important tasks is to work on mentorship for our leaders at Sastaticket - and coming across such guides such as this are always a welcome.

https://review.firstround.com/stop-overcomplicating-it-the-simple-guidebook-to-upping-your-management-game

It is a false understanding that management is about “getting work done”. And even when one is told and guided about this, we often fall into this trap again and again. Only with time, training and perseverance do we start climbing out of this pit of micro-management and deadlines and start to understand the values of trust, vision, inspiration and helping the team in order to achieve the goals set.

Trust is probably the most over-rated one. It’s the hardest one to build, and the easiest one to loose. The voice at the back of your head will constantly doubt, but over time you will learnt to control it. And understand that empowerment is the only way forward.

Feedback is the least used tool in our arsenal. A strong, and continuous feedback process is critical for any team - and more importantly feedback does not only go downwards (to the team members) but also upwards, self (reflection) and peers. Its only when we get the 360 degree view of ourselves do we understand the gaps - but unfortunately creating a culture of feedback is easier said than done. The above post also recommends manager effectiveness surveys, which also help identify weak areas across the company.

One of my favourite videos on this topic so far is done by Seth Godin. He does a great job in explaining the difference between Management and Leadership - and how not to do management which will only create mindless drones for your organisation.

One of my most important tasks is to work on mentorship for our leaders at Sastaticket - and coming across such guides such as this are always a welcome.

https://review.firstround.com/stop-overcomplicating-it-the-simple-guidebook-to-upping-your-management-game

It is a false understanding that management is about “getting work done”. And even when one is told and guided about this, we often fall into this trap again and again. Only with time, training and perseverance do we start climbing out of this pit of micro-management and deadlines and start to understand the values of trust, vision, inspiration and helping the team in order to achieve the goals set.

Trust is probably the most over-rated one. It’s the hardest one to build, and the easiest one to loose. The voice at the back of your head will constantly doubt, but over time you will learnt to control it. And understand that empowerment is the only way forward.

Feedback is the least used tool in our arsenal. A strong, and continuous feedback process is critical for any team - and more importantly feedback does not only go downwards (to the team members) but also upwards, self (reflection) and peers. Its only when we get the 360 degree view of ourselves do we understand the gaps - but unfortunately creating a culture of feedback is easier said than done. The above post also recommends manager effectiveness surveys, which also help identify weak areas across the company.

One of my favourite videos on this topic so far is done by Seth Godin. He does a great job in explaining the difference between Management and Leadership - and how not to do management which will only create mindless drones for your organisation.

Some exciting news from the #startup world. Everyone's favourite design tool Figma got bought by potentially one of the more hated companies out there, Adobe - for 20 BILLON USD! :O

Just to get a sense of how much MORE that is to similar startups in that ecosystem:

Gergely Orosz @GergelyOrosz

For those saying they are disappointed that Figma sold for ~$20B vs waiting to go public. Public companies worth less than this:\n- Box $3.8B\n- Dropbox $8B\n- Etsy $14B\n- Twilio $14B\n- Pinterest $16B\n- Coinbase $17B\n- Expedia $17B\n- Snap: $19.4B\n- Spotify $19.6B\n\nI say good choice.

Gergely Orosz @GergelyOrosz

2021 was the year when startups raising money did it on valuations that have almost all collapsed by now. Figma raised at a ~$10B valuation then.\n\nThe fact that they are selling to Adobe for close to double is nothing short of remarkable (also shows Adobe desperately needs Figma) https://t.co/N8u7OK9XBs

2:55 PM ∙ Sep 15, 2022

---

1,530Likes185Retweets

So that is crazy money - why would Adobe pay this much for Figma? Simply because Figma was taking over the design world which Adobe had monopolised for decades with the likes of Photoshop, Lightroom and more.

Im a personal user of all these tools, and 10 years ago they had the best product market fit out there. Their tools were the best and easiest to use, and because of this they were the most popular. However over the last decade their tools feel more rugged, less collaborative and require more compute resources to run. And just like that looks like Figma, took off and became a big threat to Adobe.

Lesson learnt - marketing can only go so far to get your users. If you stop focusing on the product market fit long enough, users will stop coming since they will have found something better. Not to say Adobe was not innovating, but I believe they stop listening to their users some time ago (which is why they have a general negative perception around them).

A lovely quote I read on an HN discussion:

I find myself coming back to this Steve Jobs quote more and more:

\"It turns out the same thing can happen in technology companies that get monopolies, like IBM or Xerox. If you were a product person at IBM or Xerox, so you make a better copier or computer. So what? When you have monopoly market share, the company's not any more successful. So the people that can make the company more successful are sales and marketing people, and they end up running the companies. And the product people get driven out of the decision making forums, and the companies forget what it means to make great products. The product sensibility and the product genius that brought them to that monopolistic position gets rotted out by people running these companies that have no conception of a good product versus a bad product. They have no conception of the craftsmanship that's required to take a good idea and turn it into a good product. And they really have no feeling in their hearts, usually, about wanting to really help the customers.\"

Creatives build companies, and if you are not careful, sales will destroy them. [1]

Finally - the most exciting thing as usual, it’s the money itself.

@figma, which @Adobe buying for ~$40.20 per share:\\n\\n$0.088: @dannyrimer/@IndexVentures, @semil, Jacobsen/OATV\\nA $0.199: @johnolilly/@GreylockVC \\nB $0.332: @mamoonha/@kleinerperkins \\nC $1.098: @andrew__reed/@sequoia \\nD $4.619: Peter Levine/@a16z","username":"RolfeWinkler","name":"Rolfe Winkler","date":"Thu Sep 15 17:04:41 +0000 2022","photos":[],"quoted_tweet":{},"retweet_count":392,"like_count":3444,"expanded_url":{},"video_url":null,"belowTheFold":true}\">

Rolfe Winkler @RolfeWinkler

What investors first paid for @figma, which @Adobe buying for ~$40.20 per share:\n\n$0.088: @dannyrimer/@IndexVentures, @semil, Jacobsen/OATV\nA $0.199: @johnolilly/@GreylockVC \nB $0.332: @mamoonha/@kleinerperkins \nC $1.098: @andrew__reed/@sequoia \nD $4.619: Peter Levine/@a16z

5:04 PM ∙ Sep 15, 2022

---

3,444Likes392Retweets

So thats 40X up if you joined up front, and 10x up from Series D. Thats some gains! But also to keep in mind 9 out of 10 startups fail, and probably a few in 100s give this much gains.

[1] https://news.ycombinator.com/item?id=32850178

Some exciting news from the #startup world. Everyone's favourite design tool Figma got bought by potentially one of the more hated companies out there, Adobe - for 20 BILLON USD! :O

Just to get a sense of how much MORE that is to similar startups in that ecosystem:

Gergely Orosz @GergelyOrosz

For those saying they are disappointed that Figma sold for ~$20B vs waiting to go public. Public companies worth less than this:\n- Box $3.8B\n- Dropbox $8B\n- Etsy $14B\n- Twilio $14B\n- Pinterest $16B\n- Coinbase $17B\n- Expedia $17B\n- Snap: $19.4B\n- Spotify $19.6B\n\nI say good choice.

Gergely Orosz @GergelyOrosz

2021 was the year when startups raising money did it on valuations that have almost all collapsed by now. Figma raised at a ~$10B valuation then.\n\nThe fact that they are selling to Adobe for close to double is nothing short of remarkable (also shows Adobe desperately needs Figma) https://t.co/N8u7OK9XBs

2:55 PM ∙ Sep 15, 2022

---

1,530Likes185Retweets

So that is crazy money - why would Adobe pay this much for Figma? Simply because Figma was taking over the design world which Adobe had monopolised for decades with the likes of Photoshop, Lightroom and more.

Im a personal user of all these tools, and 10 years ago they had the best product market fit out there. Their tools were the best and easiest to use, and because of this they were the most popular. However over the last decade their tools feel more rugged, less collaborative and require more compute resources to run. And just like that looks like Figma, took off and became a big threat to Adobe.

Lesson learnt - marketing can only go so far to get your users. If you stop focusing on the product market fit long enough, users will stop coming since they will have found something better. Not to say Adobe was not innovating, but I believe they stop listening to their users some time ago (which is why they have a general negative perception around them).

A lovely quote I read on an HN discussion:

I find myself coming back to this Steve Jobs quote more and more:

\"It turns out the same thing can happen in technology companies that get monopolies, like IBM or Xerox. If you were a product person at IBM or Xerox, so you make a better copier or computer. So what? When you have monopoly market share, the company's not any more successful. So the people that can make the company more successful are sales and marketing people, and they end up running the companies. And the product people get driven out of the decision making forums, and the companies forget what it means to make great products. The product sensibility and the product genius that brought them to that monopolistic position gets rotted out by people running these companies that have no conception of a good product versus a bad product. They have no conception of the craftsmanship that's required to take a good idea and turn it into a good product. And they really have no feeling in their hearts, usually, about wanting to really help the customers.\"

Creatives build companies, and if you are not careful, sales will destroy them. [1]

Finally - the most exciting thing as usual, it’s the money itself.

@figma, which @Adobe buying for ~$40.20 per share:\\n\\n$0.088: @dannyrimer/@IndexVentures, @semil, Jacobsen/OATV\\nA $0.199: @johnolilly/@GreylockVC \\nB $0.332: @mamoonha/@kleinerperkins \\nC $1.098: @andrew__reed/@sequoia \\nD $4.619: Peter Levine/@a16z","username":"RolfeWinkler","name":"Rolfe Winkler","date":"Thu Sep 15 17:04:41 +0000 2022","photos":[],"quoted_tweet":{},"retweet_count":392,"like_count":3444,"expanded_url":{},"video_url":null,"belowTheFold":true}\">

Rolfe Winkler @RolfeWinkler

What investors first paid for @figma, which @Adobe buying for ~$40.20 per share:\n\n$0.088: @dannyrimer/@IndexVentures, @semil, Jacobsen/OATV\nA $0.199: @johnolilly/@GreylockVC \nB $0.332: @mamoonha/@kleinerperkins \nC $1.098: @andrew__reed/@sequoia \nD $4.619: Peter Levine/@a16z

5:04 PM ∙ Sep 15, 2022

---

3,444Likes392Retweets

So thats 40X up if you joined up front, and 10x up from Series D. Thats some gains! But also to keep in mind 9 out of 10 startups fail, and probably a few in 100s give this much gains.

[1] https://news.ycombinator.com/item?id=32850178

When starting or working in a product company, one of the most common questions I get is around how to build the engineering team - most feel that it is one of the bigger challenges to do with building the product. However over the last decade, I have seen time and time again, once the engineers are onboarded - they get a poorly written document outlining the scope or a verbal instruction on what they should implement. While this can work in a few rare cases, I believe most of us need a slightly more structured approach to communicating what needs to be built from engineering.

If you are looking to understand on how to write user stories, then this blog post (and the associated book) are an excellent resource to start off from.

https://martinfowler.com/articles/product-backlog-building-canvas.html

We are not trying to document every detail

It’s very common for some teams to fall in the trap to document every last detail about what needs to be build far into the future. If we are doing that, then we are working in a waterfall approach. We are however trying to document the smallest possible deliverable we should like to ship in order to add value to our product. Ideally this requirement can be delivered in a single sprint.

I dont think it can be better said then by Ben Horowitz in his popular article “Good Product Manager / Bad Product Manager”:

Good product managers crisply define the target, the “what” (as opposed to the how) and manage the delivery of the “what.”

Writing is an art.

Perhaps the biggest problem with the list of shalls is the fact that it doesn’t give the stakeholder a feeling of how the product behaves. There is a long list of things the product needs to do but no information about how the product will do it. Without a feeling for how the user will interact with the product stakeholders often seem to be less engaged. They start to take the approach of indifference with the requirements solicitation phase so that development can “hurry up and start” so that they can see how the product works. This ends badly because it results in changes at the end of the project when refactoring is expensive.

https://blog.devgenius.io/the-hardest-thing-about-engineering-is-requirements-28a6a70c4db4

The first problem most of us in Pakistan run into is finding someone who has good writing skills. And that too in English (Urdu would be an option if we were any better in that). Writing a requirement or user story in a concise and accurate way is definitely a rare skill, and requires mostly to be learnt over time as you write more and more user stories. And then it’s not just about the user stories, as mentioned in the article above, we also need to document our acceptance criteria, non-functional requirements and more. All this usually creates a pretty large overhead for most product teams to create and maintain, and requires a lot of discipline to do so.

Reading is not black and white.

Unfortunately for most of us, our problems only get started. While everything is getting documented, everyone (yes everyone) has to also read it, discuss it and derive the tasks from it. So while we might be able to get away with just POs being good writers on the team, we need everyone on the team to be good readers. Everyone on the team should critically analyse each requirement, ask questions and clarify any ambiguity. We should be looking for conflicting requirements, and potential feature creep. This is often not the case (again a problem for any team where English is not their first language) which often leads to mis-communication.

User Stories should not be written only by product team.

Originally, anyone on an agile team used to write User Stories to communicate the work to be done. However, over time, largely driven by the expansion of the Scrum framework, the Product Owner became the primary person writing these stories and organizing them into a product backlog. However, anyone can (and should) write a User Story. Fábio Aguiar and I wrote our book about the Product Backlog Building technique to help everyone on the team write good user stories.

This excerpt is from the article linked above, easy to miss even though it’s right in the start. This small change has a large impact - because documentation becomes everyones responsibility. Engineers can no longer say, a particular requirement isnt documented, they are now part of the process. They also need to document the technical requirements for the given stories. QA teams writing test cases can enhance any edge cases the acceptance criteria is missing. Design teams can point out UX specific notes.

Product development is a collaborative process.

Another common mistake is for product owners to write the complete document / user story before involving other team members into the picture. So design, engineering, product, data and even quality teams need work together to outline the requirement and design the solution. This is easier said than done, each team is busy with their own work, and organising such cross functional meetings can be a huge pain for the product team. Too many of these meetings can lead to reduced focus, and pressure on delivery. This is exactly why most Big Tech companies have cross functional teams where design/engineering/product/qa/data are part of one unit working to deliver a single objective. However the balance between meeting is still something which the team need to figure out internally.

When starting or working in a product company, one of the most common questions I get is around how to build the engineering team - most feel that it is one of the bigger challenges to do with building the product. However over the last decade, I have seen time and time again, once the engineers are onboarded - they get a poorly written document outlining the scope or a verbal instruction on what they should implement. While this can work in a few rare cases, I believe most of us need a slightly more structured approach to communicating what needs to be built from engineering.

If you are looking to understand on how to write user stories, then this blog post (and the associated book) are an excellent resource to start off from.

https://martinfowler.com/articles/product-backlog-building-canvas.html

We are not trying to document every detail

It’s very common for some teams to fall in the trap to document every last detail about what needs to be build far into the future. If we are doing that, then we are working in a waterfall approach. We are however trying to document the smallest possible deliverable we should like to ship in order to add value to our product. Ideally this requirement can be delivered in a single sprint.

I dont think it can be better said then by Ben Horowitz in his popular article “Good Product Manager / Bad Product Manager”:

Good product managers crisply define the target, the “what” (as opposed to the how) and manage the delivery of the “what.”

Writing is an art.

Perhaps the biggest problem with the list of shalls is the fact that it doesn’t give the stakeholder a feeling of how the product behaves. There is a long list of things the product needs to do but no information about how the product will do it. Without a feeling for how the user will interact with the product stakeholders often seem to be less engaged. They start to take the approach of indifference with the requirements solicitation phase so that development can “hurry up and start” so that they can see how the product works. This ends badly because it results in changes at the end of the project when refactoring is expensive.

https://blog.devgenius.io/the-hardest-thing-about-engineering-is-requirements-28a6a70c4db4

The first problem most of us in Pakistan run into is finding someone who has good writing skills. And that too in English (Urdu would be an option if we were any better in that). Writing a requirement or user story in a concise and accurate way is definitely a rare skill, and requires mostly to be learnt over time as you write more and more user stories. And then it’s not just about the user stories, as mentioned in the article above, we also need to document our acceptance criteria, non-functional requirements and more. All this usually creates a pretty large overhead for most product teams to create and maintain, and requires a lot of discipline to do so.

Reading is not black and white.

Unfortunately for most of us, our problems only get started. While everything is getting documented, everyone (yes everyone) has to also read it, discuss it and derive the tasks from it. So while we might be able to get away with just POs being good writers on the team, we need everyone on the team to be good readers. Everyone on the team should critically analyse each requirement, ask questions and clarify any ambiguity. We should be looking for conflicting requirements, and potential feature creep. This is often not the case (again a problem for any team where English is not their first language) which often leads to mis-communication.

User Stories should not be written only by product team.

Originally, anyone on an agile team used to write User Stories to communicate the work to be done. However, over time, largely driven by the expansion of the Scrum framework, the Product Owner became the primary person writing these stories and organizing them into a product backlog. However, anyone can (and should) write a User Story. Fábio Aguiar and I wrote our book about the Product Backlog Building technique to help everyone on the team write good user stories.

This excerpt is from the article linked above, easy to miss even though it’s right in the start. This small change has a large impact - because documentation becomes everyones responsibility. Engineers can no longer say, a particular requirement isnt documented, they are now part of the process. They also need to document the technical requirements for the given stories. QA teams writing test cases can enhance any edge cases the acceptance criteria is missing. Design teams can point out UX specific notes.

Product development is a collaborative process.

Another common mistake is for product owners to write the complete document / user story before involving other team members into the picture. So design, engineering, product, data and even quality teams need work together to outline the requirement and design the solution. This is easier said than done, each team is busy with their own work, and organising such cross functional meetings can be a huge pain for the product team. Too many of these meetings can lead to reduced focus, and pressure on delivery. This is exactly why most Big Tech companies have cross functional teams where design/engineering/product/qa/data are part of one unit working to deliver a single objective. However the balance between meeting is still something which the team need to figure out internally.

One of the core metrics for Engineering productivity is the frequency of deployments, measured by \"number of deploys per day per developer\".

According to the book \"Accelerate by Jez Humble\" - the high performing teams deploy at the significantly increasing frequency as their team scales. This of course helps the business deliverables move faster as we add more people, not slower.

So how do we achieve this increasing frequency? By decreasing the deployment pain. The book answers:

\"teams that implement comprehensive test and deployment Automation ; use continuous integration, including trunk based development; shift left on security; effectively manage test data; use loosely coupled architectures; can work independently; and use version control of everything required to reproduce the production environment decrease their deployment pain\"

So lets break down the things mentioned in the list above:

• Comprehensive automated tests

• Deployment automation

• Trunk Based Development

• Shift Left on Security

• Loosely coupled architectures

• Can work independently

• Effectively Manage Test Data

• Use version control for everything

In the start your deployments are manual, the pain might not be so high initially (may be just a quick git pull and restarting the server?) but as the team grows, and complexity grows - you will have a more complex build pipeline, and a checklist of things to follow on every deployment. The risk of breaking the live environment increases, more steps mean greater chance of breaking something. And over time, your team will start to avoid deploying altogether - they want to play it safe. The mental drain of each deployment becomes too high, so the frequency of it gets reduced.

So the most important thing to understand is that a core part of reducing deployment pain is automation. Starting from deployment automation and then automated tests. Without these two the others have little effect on deployment pain. It’s when you start focusing on these two - another two factors will come into play, loosely coupled architectures and working independently. You will realize that deploying a large monolith comprising of 100s of services is harder than deploying any one service of them. This might lead to refactoring some code, or even writing new services so we can reduce deployment pain.

Another important point some companies make the mistakes of - considering “sprints” as review cadence rather than deployment cadence. I have seen many companies feel that deployment is done once a sprint and at the end of that sprint. Some products do have a restrictive cycle, esp. if hardware is involved - but for most of us there is no hard in shipping code on a daily basis.

Finally, just shipping fast does not ensure value generation for the business. It is also important to build the \"goal oriented generative culture” so we can also measure if our deploys are generating the required value to the business as well.

Upcoming addition:

Gergely Orosz @GergelyOrosz

If you think that big tec uses testing/staging envs… think again. Shipping to production is the new “staging”… BUT with plenty of guardrails. Facebook, Uber, and Twitter all work like that. With tenancies, feature flags, staged rollout.\n\nWrote more about it (cont’d):

Amjad Masad ⠕ @amasad

I find this incredibly hard to believe from the so called “twitter whistleblower”:\n\n“Twitter doesn’t have a development, testing, or staging environments… just has the production environment and engineers use it for testing & development — all on live data.”

8:42 AM ∙ Sep 14, 2022

---

67Likes9Retweets

How creating multiple additional staging / QA environments add to the deployment pain.

One of the core metrics for Engineering productivity is the frequency of deployments, measured by \"number of deploys per day per developer\".

According to the book \"Accelerate by Jez Humble\" - the high performing teams deploy at the significantly increasing frequency as their team scales. This of course helps the business deliverables move faster as we add more people, not slower.

So how do we achieve this increasing frequency? By decreasing the deployment pain. The book answers:

\"teams that implement comprehensive test and deployment Automation ; use continuous integration, including trunk based development; shift left on security; effectively manage test data; use loosely coupled architectures; can work independently; and use version control of everything required to reproduce the production environment decrease their deployment pain\"

So lets break down the things mentioned in the list above:

• Comprehensive automated tests

• Deployment automation

• Trunk Based Development

• Shift Left on Security

• Loosely coupled architectures

• Can work independently

• Effectively Manage Test Data

• Use version control for everything

In the start your deployments are manual, the pain might not be so high initially (may be just a quick git pull and restarting the server?) but as the team grows, and complexity grows - you will have a more complex build pipeline, and a checklist of things to follow on every deployment. The risk of breaking the live environment increases, more steps mean greater chance of breaking something. And over time, your team will start to avoid deploying altogether - they want to play it safe. The mental drain of each deployment becomes too high, so the frequency of it gets reduced.

So the most important thing to understand is that a core part of reducing deployment pain is automation. Starting from deployment automation and then automated tests. Without these two the others have little effect on deployment pain. It’s when you start focusing on these two - another two factors will come into play, loosely coupled architectures and working independently. You will realize that deploying a large monolith comprising of 100s of services is harder than deploying any one service of them. This might lead to refactoring some code, or even writing new services so we can reduce deployment pain.

Another important point some companies make the mistakes of - considering “sprints” as review cadence rather than deployment cadence. I have seen many companies feel that deployment is done once a sprint and at the end of that sprint. Some products do have a restrictive cycle, esp. if hardware is involved - but for most of us there is no hard in shipping code on a daily basis.

Finally, just shipping fast does not ensure value generation for the business. It is also important to build the \"goal oriented generative culture” so we can also measure if our deploys are generating the required value to the business as well.

Upcoming addition:

Gergely Orosz @GergelyOrosz

If you think that big tec uses testing/staging envs… think again. Shipping to production is the new “staging”… BUT with plenty of guardrails. Facebook, Uber, and Twitter all work like that. With tenancies, feature flags, staged rollout.\n\nWrote more about it (cont’d):

Amjad Masad ⠕ @amasad

I find this incredibly hard to believe from the so called “twitter whistleblower”:\n\n“Twitter doesn’t have a development, testing, or staging environments… just has the production environment and engineers use it for testing & development — all on live data.”

8:42 AM ∙ Sep 14, 2022

---

67Likes9Retweets

How creating multiple additional staging / QA environments add to the deployment pain.

Time management is one of the trickiest to do well. Personally being an efficiency maniac - i enjoy optimising every single minute of my day, and evaluating it to see if I could have used it better. Once you start doing this, you have time for *everything* - its just a matter of balance and trade offs.

For those looking to analyse their time more, I would recommend the following:

Daily Task Journal

A daily task journal to track what you are up to. I personally use Evernote for this. I would recommend:

• Starting your day by writing down all the tasks you want to focus on for the day, it sets your days agenda, and allows you to focus on delivery.

• If a higher priority task comes into the queue, consider swapping it with something you were originally planning to focus on.

• Normally you would be focusing on two to three things - ideally you don’t want a long list of never ending tasks, it becomes demotivating. Set a realistic target and finish all the tasks in it before the end of the day.

You cant improve which you do not measure.

Spending time on your tasks is fine, but we are doing soo many other things during the day, including getting distracting things like social media and Youtube etc. You can use different tools to track apps on your laptop/phone, your physical activities, calendar for meetings and other tools for things like sleep. The ones I use are below:

• RescueTime or similar on all your devices (mobile + laptop) to see how to spend your time on them.

• Mi Band or similar to track your fitness and (more importantly) sleep, how long are you sleeping and how well you are sleeping. Are you spending enough time being active, or just sitting all day?

• Google Calendar for tracking meetings, and high level blockers like visit to the doctors, community events etc.

Once you have a sense of where your time is going - you can then start optimising it. For optimisation, the rule is very simple, you are looking to remove the distractions as much as possible, and then reduce things which are not important by either delegating them or automating them.

Sleep is more important than you think

\"The moment the alarm goes off is the first test; it sets the tone for the rest of the day. The test is not a complex one: when the alarm goes off, do you get up out of bed, or do you lie there in comfort and fall back to sleep? If you have the discipline to get out of bed, you win—you pass the test. If you are mentally weak for that moment and you let that weakness keep you in bed, you fail. Though it seems small, that weakness translates to more significant decisions. But if you exercise discipline, that too translates to more substantial elements of your life.\" - Extreme Ownership by Jocko

Sleep takes about 30% of the time in our life, and has the largest impact on productivity during the day. This is the single best optimization you can do to your life. Everyone is different and some people are better at getting away with sleep than others, but everyone does eventually need to rest to ensure best output.

I have already talked about measuring sleep. I would also recommend understanding it more. Get a feel for what works for you, helps you start fresh in the morning and helps you stay focused during the day. For _most_ people having a regular pattern (i.e. fixed time for going to sleep and waking up) has a an overall positive effect on your sleep cycles.

One common “issue” with waking up I have seen is an un-optimised sleep cycle (i.e. waking up during deep sleep cycle). Study them to get a better understanding of how this can work better for you.

Multi-tasking does work for specific cases.

While this is not something you should be looking to do all the time, there are specific combinations where this is useful. Things where you are doing some repetitive work, which doesn’t require your full focus - like some low intensity exercise, commuting etc are ideal times to spend listening to audio books, podcasts or even spend some time in deep thought. Once you actively start looking for opportunities you will find such options within your daily activities.

#goldenrule
Don't try to make everything time efficient - some things like spending time on your family and religion are not designed to be optimised.

This is an evolving article and I will keep adding more thoughts to this over time.

Time management is one of the trickiest to do well. Personally being an efficiency maniac - i enjoy optimising every single minute of my day, and evaluating it to see if I could have used it better. Once you start doing this, you have time for *everything* - its just a matter of balance and trade offs.

For those looking to analyse their time more, I would recommend the following:

Daily Task Journal

A daily task journal to track what you are up to. I personally use Evernote for this. I would recommend:

• Starting your day by writing down all the tasks you want to focus on for the day, it sets your days agenda, and allows you to focus on delivery.

• If a higher priority task comes into the queue, consider swapping it with something you were originally planning to focus on.

• Normally you would be focusing on two to three things - ideally you don’t want a long list of never ending tasks, it becomes demotivating. Set a realistic target and finish all the tasks in it before the end of the day.

You cant improve which you do not measure.

Spending time on your tasks is fine, but we are doing soo many other things during the day, including getting distracting things like social media and Youtube etc. You can use different tools to track apps on your laptop/phone, your physical activities, calendar for meetings and other tools for things like sleep. The ones I use are below:

• RescueTime or similar on all your devices (mobile + laptop) to see how to spend your time on them.

• Mi Band or similar to track your fitness and (more importantly) sleep, how long are you sleeping and how well you are sleeping. Are you spending enough time being active, or just sitting all day?

• Google Calendar for tracking meetings, and high level blockers like visit to the doctors, community events etc.

Once you have a sense of where your time is going - you can then start optimising it. For optimisation, the rule is very simple, you are looking to remove the distractions as much as possible, and then reduce things which are not important by either delegating them or automating them.

Sleep is more important than you think

\"The moment the alarm goes off is the first test; it sets the tone for the rest of the day. The test is not a complex one: when the alarm goes off, do you get up out of bed, or do you lie there in comfort and fall back to sleep? If you have the discipline to get out of bed, you win—you pass the test. If you are mentally weak for that moment and you let that weakness keep you in bed, you fail. Though it seems small, that weakness translates to more significant decisions. But if you exercise discipline, that too translates to more substantial elements of your life.\" - Extreme Ownership by Jocko

Sleep takes about 30% of the time in our life, and has the largest impact on productivity during the day. This is the single best optimization you can do to your life. Everyone is different and some people are better at getting away with sleep than others, but everyone does eventually need to rest to ensure best output.

I have already talked about measuring sleep. I would also recommend understanding it more. Get a feel for what works for you, helps you start fresh in the morning and helps you stay focused during the day. For _most_ people having a regular pattern (i.e. fixed time for going to sleep and waking up) has a an overall positive effect on your sleep cycles.

One common “issue” with waking up I have seen is an un-optimised sleep cycle (i.e. waking up during deep sleep cycle). Study them to get a better understanding of how this can work better for you.

Multi-tasking does work for specific cases.

While this is not something you should be looking to do all the time, there are specific combinations where this is useful. Things where you are doing some repetitive work, which doesn’t require your full focus - like some low intensity exercise, commuting etc are ideal times to spend listening to audio books, podcasts or even spend some time in deep thought. Once you actively start looking for opportunities you will find such options within your daily activities.

#goldenrule
Don't try to make everything time efficient - some things like spending time on your family and religion are not designed to be optimised.

This is an evolving article and I will keep adding more thoughts to this over time.

With all the companies around me downsizing and / or freezing hiring now a days - one does start wondering about team sizing and the optimal team size. A sample from the posts:

https://www.theverge.com/2022/7/12/23206113/google-ceo-sundar-pichai-memo-hiring-slowdown-2022

Now Google and Facebook are large organisations and one can forgive them if they hired a dozen more engineers (to better manage turnover may be) - but there looks to be a concern where it is felt that the teams are generally not fully optimised, and are being pushed to more efficient and “do more with less”. Zuckerberg is heard saying out right that some folks are not working at all. Now this is a pretty expected response to a global economic slow down - but it does make one think if their teams are at an optimal limit or not.

Hiring fast and building big teams is a pretty standard culture thing in the startup world. It’s actually very hard to know how “big” a team is needed initially, since there is so much to do and everything is high priority. But its not just about hiring software engineers, in order to solve _a_ problem you also need to need to hire product managers, designers and other roles to get the ball rolling - even the best engineering team is pretty useless without equally good product/design folks.

Another problem with building teams quickly is productivity. It is virtually impossible to hire fast and also keep the whole team productive the same time. Since hiring itself is a pretty intense activity you would expect several folks to be engaged in reviewing profiles, interviewing, onboarding etc. And with the introduction of each team member, the “gelling” process starts. You need to bring them up to speed, show them the ropes and adjust to their communication and personality quirks. Team compatibility is a related problem, some people don’t work well together and need to be moved around. Some are not the best fit and need to let go.

So most startups (and companies) will size their teams according to their planned budget. This is mostly an estimated budget based on a percentage of current / future revenue for startups, or money raised from VCs. Once the budget is established we can break it down into the requirements for the headcount depending on the number of teams we have, seniority we require (and can realistically hire for) and specialisations.

The advantage of the above is that you can get all the folks you need in one swoop, and then reduce the overhead of the continuous hiring in the coming months. But in the real world, it never happens this way - hiring is a continuous process - simply because its usually impossible to hire all the folks in one go unless you are acqui-hiring a team.

So the best way to manage this is to focus on team productivity using different tools, focus on completing a specific team first and then let them gel, while focus moves onto other teams. It’s important not to create one person teams - only split larger teams into 2 smaller ones when there are enough people. And the hiring usually slows down when the budget limit reaches.

There is a solid chapter on this in Will Larson’s book - An Elegant Puzzle.

https://www.amazon.com/Elegant-Puzzle-Systems-Engineering-Management/dp/1732265186

With all the companies around me downsizing and / or freezing hiring now a days - one does start wondering about team sizing and the optimal team size. A sample from the posts:

https://www.theverge.com/2022/7/12/23206113/google-ceo-sundar-pichai-memo-hiring-slowdown-2022

Now Google and Facebook are large organisations and one can forgive them if they hired a dozen more engineers (to better manage turnover may be) - but there looks to be a concern where it is felt that the teams are generally not fully optimised, and are being pushed to more efficient and “do more with less”. Zuckerberg is heard saying out right that some folks are not working at all. Now this is a pretty expected response to a global economic slow down - but it does make one think if their teams are at an optimal limit or not.

Hiring fast and building big teams is a pretty standard culture thing in the startup world. It’s actually very hard to know how “big” a team is needed initially, since there is so much to do and everything is high priority. But its not just about hiring software engineers, in order to solve _a_ problem you also need to need to hire product managers, designers and other roles to get the ball rolling - even the best engineering team is pretty useless without equally good product/design folks.

Another problem with building teams quickly is productivity. It is virtually impossible to hire fast and also keep the whole team productive the same time. Since hiring itself is a pretty intense activity you would expect several folks to be engaged in reviewing profiles, interviewing, onboarding etc. And with the introduction of each team member, the “gelling” process starts. You need to bring them up to speed, show them the ropes and adjust to their communication and personality quirks. Team compatibility is a related problem, some people don’t work well together and need to be moved around. Some are not the best fit and need to let go.

So most startups (and companies) will size their teams according to their planned budget. This is mostly an estimated budget based on a percentage of current / future revenue for startups, or money raised from VCs. Once the budget is established we can break it down into the requirements for the headcount depending on the number of teams we have, seniority we require (and can realistically hire for) and specialisations.

The advantage of the above is that you can get all the folks you need in one swoop, and then reduce the overhead of the continuous hiring in the coming months. But in the real world, it never happens this way - hiring is a continuous process - simply because its usually impossible to hire all the folks in one go unless you are acqui-hiring a team.

So the best way to manage this is to focus on team productivity using different tools, focus on completing a specific team first and then let them gel, while focus moves onto other teams. It’s important not to create one person teams - only split larger teams into 2 smaller ones when there are enough people. And the hiring usually slows down when the budget limit reaches.

There is a solid chapter on this in Will Larson’s book - An Elegant Puzzle.

https://www.amazon.com/Elegant-Puzzle-Systems-Engineering-Management/dp/1732265186

An interesting discussion (and a good article to read as well) on how big consultancies can fail some times.

https://news.ycombinator.com/item?id=32184183

One of the biggest challenges with any consultancy is domain knowledge - thats the one thing I have learnt after joining Sastaticket. Domain knowledge is so critical (along with its documentation and communication) that a simple feature can become a nightmare due to mis-communication. Bringing all stakeholders to use the same language and the same perspective is a very hard problem to solve.

A great example of this was the implementation of a specific check on our Sastaticket.pk website - restricting the user to make duplicate bookings. This is important for us since we get penalties from airlines (called ADMs), and even though this is a simple check - understanding its edge cases, impact on customer support and overall user experience is essential. And this understanding comes with close collaboration of our customer support team, product team, design team and engineering. The back and forth discussions and understanding takes time to build. It’s not just a task on someones board they need to complete and move on.

This is specially critical for startups. As we work towards finding the product market fit, and giving the user the best experience possible - things are precariously balanced with every decision we take. And if those executing do not have a part of the stake - then the results are best varied.

Im not saying you cant have good work delivered this way - but its how we normally execute this. For example take this from a team alignment perspective. Consultancy has a different goal, and your team members have a different goal. This usually ends poorly for both teams.

Another area which sticks out sorely is the engineering mindset, an excellent article here on why India is struggling with finding the right engineers.

https://edition.cnn.com/2021/09/09/tech/india-software-saas-intl-hnk/index.html

\"Indian engineers trained in the IT services industry may find it hard to develop the discipline required to build a product-focused company.

In IT services, \"you are selling bodies and you say yes to everything the customer says,\" said Krishnamoorthy. SaaS companies, on the other hand, have to say no to 99% of [potential] customers, he added.\"

The shift from consultancy to product requires you to question your requirements, understand their business use-case and even speak with the customers or stakeholders. This is in stark contrast to how normally engineers work in a consultancy, usually “behind” a project manager, and are not allowed to question the requirements of the client or understand why they are needed. The resulting output is very different - which is the focus - consultancy would end up focusing more on the task, the product engineer would focus on the users problem and if he’s actually solving that.

Working with a consultancy is an art - and my recommendation is to try to make it into a long term partnership rather than shipping a “project” - it will cost a lot more - but at least there will be some thought put into it. Otherwise I would recommend building a team, with likeminded passionate devs who want to solve the problem you are working on.

An interesting discussion (and a good article to read as well) on how big consultancies can fail some times.

https://news.ycombinator.com/item?id=32184183

One of the biggest challenges with any consultancy is domain knowledge - thats the one thing I have learnt after joining Sastaticket. Domain knowledge is so critical (along with its documentation and communication) that a simple feature can become a nightmare due to mis-communication. Bringing all stakeholders to use the same language and the same perspective is a very hard problem to solve.

A great example of this was the implementation of a specific check on our Sastaticket.pk website - restricting the user to make duplicate bookings. This is important for us since we get penalties from airlines (called ADMs), and even though this is a simple check - understanding its edge cases, impact on customer support and overall user experience is essential. And this understanding comes with close collaboration of our customer support team, product team, design team and engineering. The back and forth discussions and understanding takes time to build. It’s not just a task on someones board they need to complete and move on.

This is specially critical for startups. As we work towards finding the product market fit, and giving the user the best experience possible - things are precariously balanced with every decision we take. And if those executing do not have a part of the stake - then the results are best varied.

Im not saying you cant have good work delivered this way - but its how we normally execute this. For example take this from a team alignment perspective. Consultancy has a different goal, and your team members have a different goal. This usually ends poorly for both teams.

Another area which sticks out sorely is the engineering mindset, an excellent article here on why India is struggling with finding the right engineers.

https://edition.cnn.com/2021/09/09/tech/india-software-saas-intl-hnk/index.html

\"Indian engineers trained in the IT services industry may find it hard to develop the discipline required to build a product-focused company.

In IT services, \"you are selling bodies and you say yes to everything the customer says,\" said Krishnamoorthy. SaaS companies, on the other hand, have to say no to 99% of [potential] customers, he added.\"

The shift from consultancy to product requires you to question your requirements, understand their business use-case and even speak with the customers or stakeholders. This is in stark contrast to how normally engineers work in a consultancy, usually “behind” a project manager, and are not allowed to question the requirements of the client or understand why they are needed. The resulting output is very different - which is the focus - consultancy would end up focusing more on the task, the product engineer would focus on the users problem and if he’s actually solving that.

Working with a consultancy is an art - and my recommendation is to try to make it into a long term partnership rather than shipping a “project” - it will cost a lot more - but at least there will be some thought put into it. Otherwise I would recommend building a team, with likeminded passionate devs who want to solve the problem you are working on.

Yesterday Cloudflare (worlds largest CDN) suffered an outage while deploying some enhancements to their network. We at Sastaticket.pk were also impacted in this outage.

Now I am pretty sure Cloudflare has the best engineers, and a solid test suite and a rigorous engineering process. However at the end of the day, it is people who build the product - and people sometimes make mistakes, some times miss out specific things.

So even in the best companies in the world we can have an outage - and sometimes it takes out a large portion of the internet. But the thing to focus on here is not that the outage happened, but how fast they were able to detect it (5 mins), find and fix the issue (30 mins) and recover from it (40 mins) [at global scale].

This is a core part of Continuous Delivery - having the correct observability tooling to detect changes and help diagnose the issues, and then a fast automated pipeline to help deploy (or revert) the changes as needed. And once all is said and done, a good post mortem (like the link below) to help understand the cause and setting up actions to avoid it in the future.

Strongly recommend reading the post mortem for better understanding of how things are done at Cloudflare.

https://blog.cloudflare.com/cloudflare-outage-on-june-21-2022/

Share

Yesterday Cloudflare (worlds largest CDN) suffered an outage while deploying some enhancements to their network. We at Sastaticket.pk were also impacted in this outage.

Now I am pretty sure Cloudflare has the best engineers, and a solid test suite and a rigorous engineering process. However at the end of the day, it is people who build the product - and people sometimes make mistakes, some times miss out specific things.

So even in the best companies in the world we can have an outage - and sometimes it takes out a large portion of the internet. But the thing to focus on here is not that the outage happened, but how fast they were able to detect it (5 mins), find and fix the issue (30 mins) and recover from it (40 mins) [at global scale].

This is a core part of Continuous Delivery - having the correct observability tooling to detect changes and help diagnose the issues, and then a fast automated pipeline to help deploy (or revert) the changes as needed. And once all is said and done, a good post mortem (like the link below) to help understand the cause and setting up actions to avoid it in the future.

Strongly recommend reading the post mortem for better understanding of how things are done at Cloudflare.

https://blog.cloudflare.com/cloudflare-outage-on-june-21-2022/

Share

When managing #engineering teams - one challenge is often to balance the work between new features (innovation) and fixing bugs or adjusting older features (maintenance). This excerpt from \"An Elegant Puzzle\" by Will Larson is spot on about managing both aspecting from the same team rather than splitting the work between two teams.

This helps the team cycle through old and new stuff at the same time, so they have good knowledge about the old systems, and are happy to learn new things when creating the next generation stuff.

One additional tricky aspect of this is issues rolling in which need to be tackled during a sprint or feature development. Having a dedicated \"hot-fix\" crew (within your team) helps the team focus on their work and not get distracted by the new issues.

When managing #engineering teams - one challenge is often to balance the work between new features (innovation) and fixing bugs or adjusting older features (maintenance). This excerpt from \"An Elegant Puzzle\" by Will Larson is spot on about managing both aspecting from the same team rather than splitting the work between two teams.

This helps the team cycle through old and new stuff at the same time, so they have good knowledge about the old systems, and are happy to learn new things when creating the next generation stuff.

One additional tricky aspect of this is issues rolling in which need to be tackled during a sprint or feature development. Having a dedicated \"hot-fix\" crew (within your team) helps the team focus on their work and not get distracted by the new issues.

So a bug in DoorDash payment system lead to hundreds of free food orders last week. Millions of dollars lost in compensation and many customers ended up getting a poor experience as well. You can read more about it here:

https://mashable.com/article/doordash-glitch-free-food

What can we learn from this event?

Things to think about:
- What sort of validation do we have in place to stop such an event from happening?
- Do we have automated tests testing for this specific scenario?
- Does our QA check for such issues with our out going builds?
- What metrics are being tracked in our monitoring and observability apps, which could trigger an alert for such an issue?
- How would we debug such an issue quickly so keep the losses at a minimum?
- Are our deployment pipeline fast enough to quickly patch this issue?

Adding each layer, reduces the probability of this happening, and even if this does happen it ensures its caught quickly and turned around before it comes a bit issue for the company.

Share

So a bug in DoorDash payment system lead to hundreds of free food orders last week. Millions of dollars lost in compensation and many customers ended up getting a poor experience as well. You can read more about it here:

https://mashable.com/article/doordash-glitch-free-food

What can we learn from this event?

Things to think about:
- What sort of validation do we have in place to stop such an event from happening?
- Do we have automated tests testing for this specific scenario?
- Does our QA check for such issues with our out going builds?
- What metrics are being tracked in our monitoring and observability apps, which could trigger an alert for such an issue?
- How would we debug such an issue quickly so keep the losses at a minimum?
- Are our deployment pipeline fast enough to quickly patch this issue?

Adding each layer, reduces the probability of this happening, and even if this does happen it ensures its caught quickly and turned around before it comes a bit issue for the company.

Share

An excellent post by an x-spotify engineer sharing several important lessons from his time there. Strongly recommend reading the whole thing..

https://www.jeremiahlee.com/posts/failed-squad-goals/

My favourite one from all of them is one below - something I have also personally learnt while building the best travel platform at Sastaticket.pk - product and engineering alignment is one of the hardest things to get right in any product startup.

\"Product managers should have an equivalent peer for engineering. Product managers should be accountable for the prioritization of work. Engineering managers should be accountable for the engineers’ execution, which includes being able to negotiate speed and quality tradeoffs with the product manager.\"

Share

An excellent post by an x-spotify engineer sharing several important lessons from his time there. Strongly recommend reading the whole thing..

https://www.jeremiahlee.com/posts/failed-squad-goals/

My favourite one from all of them is one below - something I have also personally learnt while building the best travel platform at Sastaticket.pk - product and engineering alignment is one of the hardest things to get right in any product startup.

\"Product managers should have an equivalent peer for engineering. Product managers should be accountable for the prioritization of work. Engineering managers should be accountable for the engineers’ execution, which includes being able to negotiate speed and quality tradeoffs with the product manager.\"

Share

Been thinking about what makes different teams stand out - the same work done by 2 different teams or companies can be very different. The article below shares a very nice perspective on how people or teams tend to think - and why certain startups are so good with their products.

https://allenpike.com/2022/giving-a-shit

If we align the whole company to focus on the customer, and remove all distractions around them (like number of hours worked or meeting that specific deadline) then with the right training, the team can actually start looking at customer problems and focus on solving them. So everything else in the company, becomes transient be it the scrum meetings, our performance reviews or even our growth targets. If the customers problem isn't solved then what is the point of even working on this product?

Creating such a culture is easier said than done.

Some things which I feel help set the right course include:
- Setting a strong purpose and vision statements.
- Regular town halls where we get to revisit this purpose and vision.
- A system of goals - top down, which drives this vision and purpose.
- Transparency which helps everyone to see the different problems, and chip in where needed.
- Empowering the teams to lead with problems, and giving them the right tools to solve them.

Subscribe now

Share

Been thinking about what makes different teams stand out - the same work done by 2 different teams or companies can be very different. The article below shares a very nice perspective on how people or teams tend to think - and why certain startups are so good with their products.

https://allenpike.com/2022/giving-a-shit

If we align the whole company to focus on the customer, and remove all distractions around them (like number of hours worked or meeting that specific deadline) then with the right training, the team can actually start looking at customer problems and focus on solving them. So everything else in the company, becomes transient be it the scrum meetings, our performance reviews or even our growth targets. If the customers problem isn't solved then what is the point of even working on this product?

Creating such a culture is easier said than done.

Some things which I feel help set the right course include:
- Setting a strong purpose and vision statements.
- Regular town halls where we get to revisit this purpose and vision.
- A system of goals - top down, which drives this vision and purpose.
- Transparency which helps everyone to see the different problems, and chip in where needed.
- Empowering the teams to lead with problems, and giving them the right tools to solve them.

Subscribe now

Share