If You Can Do Your Job From Home, Be Scared. Be Very Scared!

By [email protected] | July 2, 2023 | Comments 0 Comment

Sometimes, It seems like most people have added “Remote Work” to a long list of taboo topics that no one should discuss at work. Topics like Religion, Politics, Sexual Orientation, Medical Issues, etc.

Most people know that remote work is a horrible idea for organisations of any size, but they are afraid to call it out because they don’t want to appear out of touch with their employees/colleagues. Others are afraid to be viewed as hostile figures who wish to create tension with employees or be perceived as a manager who doesn’t trust their employees.

So, employers stay silent, and now everyone thinks remote work is the best business idea of the last 200 years.

Most of these shenanigans use personal anecdotes to defend the benefit of remote work. They say they are more productive at home, with fewer distractions and more time for daily (personal) chores. I do not agree or disagree with that statement completely, as it could be dependent on specific roles.

When Remote Work Could be Beneficial:

If you are an individual contributor and mostly work without the need to collaborate in real time, you can be productive in remote work. For example, If you are a finance analyst who dives through ledgers, borough thru tonnes of CSVs and crunch numbers all day, you may be more productive in Home.

When Remote work could be less than Optimal

If you are a creative or knowledge worker (Designer/Developer), chances are you’d NEED to collaborate with, break down/delegate, get feedback etc. In these roles, it will be almost impossible to get a calendar from 6 different people to drive consensus. Whereas if all of your stakeholders are in the office, it is a mere “Shout” or “Wave” and 3 mins conversation following it.

Google has officially changed its mind about remote work

Google leadership publicly admitted that remote work no longer works for them, and that’s the reason they want all of their employees back behind their desks.

Last week, Fiona Cicconi, Google’s chief people officer, wrote an email to the entire company stating, “Going forward, we’ll consider new remote work requests by exception only.” This is horrible news for employees and some companies who believe that remote work is the greatest idea since the invention of the internet.

Let me declutter the above statement for you.

Google is the biggest tech company in the world that created 100s of resources and tools to enable employees to work remotely, admitting defeat.

Despite the release of many communications tools that enabled workers across the globe and all industries to work remotely, it is finally saying that remote work doesn’t work. Let that sink in. Google’s remote employees are unhappy, but Google’s leadership rarely pay attention to the feeling of their employees (after Larry left Alphabet inc). They only pay attention to the stock price and what is recommended at the shareholder’s meeting.

Google is not alone. Apple, Microsoft, Facebook, and Amazon also laid off most remote employees.

Remote work destroyed the most profitable industry

As you have seen above, Google leadership is no longer willing to offer their employees 100% remote jobs. They want their employees in the office and productive.

You might ask, why is this happening?

It is happening because you witnessed the destruction of the Tech industry in the last two years. The tech industry crumbled because most Leaders were afraid to tell their remote employees to come to the office, so they did the next best thing: they lost money and laid remote employees off (mostly).

According to the Layoffs tracker, more than 200,000 people were laid off in 2023, and over 164,000 employees were laid off in 2022. This is a clear message to anyone who works in the tech industry, stop working remotely or start interviewing soon.

This is exactly what the most innovative CEO in the world did when he bought Twitter.

When Elon Musk bought Twitter, he found the company in tatters. Musk gave them the same two options he gave his Tesla employees, “If you do not return to the office, you cannot remain at the company. End of story.”

That was the end of the story for many of Twitter’s employees, Musk fired anyone who refused to show up at the office, and his company is more productive and innovative than ever.

Musk ended remote work at Twitter, and most people hated him.

Not every executive had the guts to do what Elon Musk did, but now most wish they did because every company needs to lay off their unproductive employees.

Remote employees are less visible. When it comes to your value to your company, you have to be visible. If you think visibility is not important, ask Kayne West.
Remote employees don’t have a strong connection to other employees or their companies. Relationships are extremely important. I established my professional credibility and earned my colleagues’ respect by connecting with them face-to-face, not through a computer screen.
Remote employees are less invested in their work or career. Since most employer link visibility and ability together, I understand why more than 3000 HR managers believe that.

These reasons led Google, Microsoft, Amazon, Facebook, and Zoom to lay off their remote employees first. This is a horrible trend for people who want to work remotely, especially since most remote workers say it could take more than six months to find a new job

In conclusion, I’d like to recommend Richard Baldwin’s video

Is the myth of a “10X Developer” Real?

By [email protected] | June 29, 2023 | Comments 0 Comment

If you’re a software engineer, manager or leader, I am sure you have heard the term ‘10x developer’ used in discussions. It refers to developers who are purportedly 10 times more productive, or capable, than their peers, while it is a hotly contested category. Some refer to it very liberally, others deny that it even exists. In the last 40+ years, the ‘10X developer` has become a ‘Loch Ness` of the tech world, fueled by the hype associated with Silicon Valley.

I’m not about to delude myself into thinking that writing a blog on it to pass my verdict will put these theories to rest, but the question has gained enough traction that it deserves a little articulation.

Do 10x developers really exist, and if so, how would we distinguish them?

Framing the Issue

All of us can acknowledge that the range of skills in most human activities can be extensive. A marathon runner can cover roughly 10 times the distance that an untrained person could, while a professional chef can cook a 5-course meal in 1/5th the time it takes an average person to do a 2-course meal.

Coding, which is a hugely complex field unencumbered by physical limitations, should naturally show differences in the skill that vary by orders of magnitude. Thus, if by 10x developer we simply mean a person whose skill level is in a different league compared to someone else, then clearly they exist.

How could anyone argue otherwise?

Here’s the rub though, in the data-driven and lexically precise world of modern tech, that’s not what 10x developer means. Instead, a 10x developer is supposed to be someone who genuinely outperforms others by 10 times or more on some quantifiable scale. That ‘quantifiable scale’ is where the problems start.

Where did the term actually come from? Enter Coding War Games.

Coding War Games

Tom DeMarco and Tim Lister have conducted the “Coding War Games” since 1977. This is a public productivity survey in which teams of software implementors from different organizations compete to complete a series of benchmarks in minimal time with minimal defects. They’ve had over 600 developers participate. Its results are publicly available and is very informative, to say the least. Jeff Lester published a wonderful piece on the origins of the 10X developer here.

The top findings from these are,

1, Get your working environment Right

The overriding observation from this study is that quiet, private, dedicated working space with fewer interruptions led to groups that performed significantly better.

2, Remove the Net Negative Producing Programmer

Some developers are “net negative producing programmers” (NNPP), that is they produce so many defects that removing them from the team increases productivity. This is the opposite of a 10X developer, these people are the ones that make the team productivity go from bad to worse.

The Problem with Measuring ‘Skill’

Even where skill can vary wildly, differences will not necessarily be quantifiable. A talented artist may know how to create a painting that teleports you to a whole other world compared to an average artiste who can transport you to the scene.

But the question is, can you attach numbers to that painting’s beauty?

The work of a developer isn’t nearly as abstract, but not all of it can be reduced to metrics either, and definitely not the programming skill itself.

A less glamorous approach may be to judge a 10x dev not in terms of skill but in terms of productivity. Someone who can write 500 lines of code when it takes others to write 50 would then fall in that category.

If you know anything about programming, however, you’ve probably already spotted the problem with this line of thinking. Longer code isn’t necessarily more efficient, and for most people there tends to be a positive correlation between how quickly one works and how many bugs one creates.

This is not to say that programmers can’t produce bug-free code much faster than their peers. Where this statement proves fallacious though, is in trying to peg that difference to a single metric. There are myriad factors at play that will affect a developer’s productivity outside of their skill, including their team and the environment they find themselves. In fact, depending on the situation, the 10x tag may be inaccurate because a developer could be programming well over 10 times as much as another and still produce 1/10th of the ‘Outcomes’!

What should be our conclusion? There can be no doubt that the field of programming has its own Mozarts and Vincent Van Goghs, and few would object if these people were described as being ‘orders of magnitude’ better than the rest. But it is important to recognize that this is only a figure of speech, and not something meant to be used according to its precise quantitative meaning.

I can’t presume to speak for the tech industry as a whole, but I for one have noticed a worrying tendency to read the expression ‘10x developer’ literally.

Ultimately this does more harm than good, as it spreads the myth that there is some universal metric whereby every programmer’s value can always be quantified.

Important qualities like creativity, client focus and teamwork are entirely omitted in this way of thinking, which is why my final suggestion is to stop worrying about lofty 10x developers and whether you are, aren’t, or may or not become one.

Simply focus on being the best developer you can be. That will always be enough.

References & Further Reading

Origin of a 10X developer

https://medium.com/ingeniouslysimple/the-origins-of-the-10x-developer-2e0177ecef60

https://gwern.net/doc/cs/algorithm/2001-demarco-peopleware-whymeasureperformance.pdf

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

The 10x Programmer Myth

Is Pedigree and Old Boy network really relevant in the 21st Century?

By [email protected] | June 27, 2023 | Comments 0 Comment

Not sure how to categorise this post, it’s an amalgamation of a critique of the social stratification that we witness today with a fair amount of my experiences interspaced and viewed through the lenses of a book, Pedigree. I have always held that Pedigree and education from Elite Institutions are a bit overrated and are not necessarily an indication of capability or skill, but rather of discipline and or perseverance.

Prior to my arrival in the United Kingdom eleven years ago, I had a very different picture of effort and success in the world. I assumed that professional success was not just a possibility, but a certainty if you were skilled and worked hard. Especially, after you read things like the 10000-hour rule (Outliers) or the 67 Principles (The success principle). Nothing seemed to be able to stop the onslaught of hard-working smart people’s success. My personal yardstick was, of course, me. After all, here I am in the heart of London building the very first meta-search engine for betting odds (in the UK) leading a team across 3 continents.

Imagine a tortoise roll aka Flashbak scenes from Masala movies:

I did not have the “Blue Blood” in me, I graduated with an Electronics degree from a Tier 2 University in South India. To make it abundantly clear, the first time I had come to the state capital, Madras (now Chennai) was to enrol in IEEE student chapter and the second was to apply for a passport! So, you can guess my “exposure”, the fact that I even got to know that something called IITs exists is a testament to the wonderful Teachers I had during my school days. Anyway, from there, it took me 3 different jobs (one of which was for Paypal), my own entrepreneurship journey and a successful exit to hitch this stint with EasyOdds/MarCol group.

Going through this and seeing my peers with a similar trajectory, I could be forgiven for thinking this is how success looks, a slow march with perseverance and dedication and “years under the belt”. This is not just me, but most people I knew did think that the recipe for success is the long game. This couldn’t be far from the truth. We have been oblivious to the fact that two classes exist in any workforce, the elites and the others! I started noticing that people with degrees from “fancy institutions” climb the ladder much faster or even start from a higher step. Now, Rivera starts her book by saying,

“Most Americans believe that hard work- not blue blood- is the key to success.”
Pedigree: How Elite Students Get Elite Jobs.

Rivera is a Professor at Northwestern University’s Kellogg School of Management and has received her Ph.D. in sociology from Harvard University. She has spent around a year researching her book by working in the HR department of a major New York City consulting firm.

Rivera starts her book by discussing and pinpointing the macroeconomic environment that sets “elite” students from “other” students. She uses a lot of data analysis throughout her book, (some of them went right over my head). The book is categorized as “vocational guidance” on Amazon! However, the book doesn’t directly guide you to secure an “elite” job! So, do not bother. Instead, the book is a critique of the hiring process and reveals the actions of those responsible for hiring. The book’s thesis is “that the way in which elite employers define and evaluate “merit” in hiring strongly tilts the playing field for America’s highest paying jobs toward children from socioeconomically privileged backgrounds.”

However, in her last chapter, she makes sure to show that the hiring process isn’t completely rigged and that some candidates from less affluent backgrounds were able to break the code and get hired while other candidates with affluent backgrounds failed to get hired. But, as stated earlier this is rare and not the norm. The author does a really good job by chronologically taking the reader through the steps of the hiring process, “from the initial decision (of firms) of where to post job advertisements to the final step, when the hiring committee meets to make final offer and rejection decisions.”

Rivera does a good job of explaining earlier in the book how the reproduction of elites starts from a very young age during college and that “Today, the transition of economic privilege from one generation to the next tends to be indirect. It operates largely through the education system” (3) She follows up by using the sociological research conducted by Alexandra Radford in which she shows that many top achieving high school valedictorians “from lower-income families do not apply to prestigious, private, four year universities because the high price tags associated with these schools. Illustrating how money and cultural know-how work together, some who would have qualified for generous financial aid packages from these institutions did not apply because they were unaware of such opportunities. Other had difficulty obtaining the extensive documentation required for financial aid applications.” (5) Since these students are unfortunately unable to apply to “elite” schools they are also unable to apply to “elite” EPS firms that only hire from a select number of IVY league schools. Therefore, as one of the attorneys said in the opening of the second chapter, “There are many smart people out there. We just refuse to look at them”. Why? Because they primarily hire from a select number of schools which are accessible to a select few. Therefore, the universities are the “engines of inequality” as she says in her book. Rivera points out that there are two methods of allocating high status career opportunities. One is the contest system, in which competition is open to all and success is based on competence. The other is the sponsored system in which existing elites select the winners, either directly or through third parties. The system in the U.S is a combination of both models according to Rivera. However, what is better for a society’s institutions? A combination of both models or strictly a contest system? It seems quite clear that a contest system would certainly drive the most deserving and competent students to the jobs that suit them. However, that’s unfortunately not the case as earlier stated through the attorney. Does this not seem like an irony in age where shareholder maximization seems like the first commandment of firms today? It certainly is. Where is the efficiency? It’s traded off for the sake of job “fit” and “polish”. According to Rivera’s study more than half of the evaluators of applicants regarded fit “as the most important criterion at the job interview stage, rating it above analytical skills and polish.” But what is fit?

According to Rivera’s sample of evaluators they defined and measured fit saying that it means they have a similarity in “play styles- how applicants preferred to conduct themselves outside the office- rather than in their work styles or job skills. In particular, they looked for matches in leisure pursuits, backgrounds, and self-presentation styles between candidates and firm employees (including themselves)” (137). This definition of fit unfortunately tilts the hiring process in favor of the already dominant elite while rejecting the competent and hardworking yet “unfit” candidates. Furthermore, it results in a monoculture where homphily is the norm and widely practiced. Yes, fit might generate stronger cohesion among employees, but a diverse number of competent employees from diverse backgrounds can certainly be healthier for society by motivating employees to work harder while increasing efficiency. Another metric that Rivera mentioned was Polish. Now what is Polish? Well, according to Rivera “interviewers in my study initially had difficult explaining to me how they recognized and assessed polish during job interviews.” (171) One Banker went so far that she likened polish to pornography, laughingly saying, “You kind of know it when you see it”. The general idea of Polish is that firms want to recruit employees who can maintain a reputable, luxurious and elite picture of the firm they represent. One consultant Natalie said, “In an ideal world, you have people who are folks that you want to throw in front of a client, that you feel are professional and mature. People that you know can walk into a room full of people who are twice their age ad be able to command it with self-confidence, but not too much self-confidence.” (170) Although, this might certainly be a good thing for a hiring firm it might also be a bias for those with families that have executives in the family and have taught their children to deal with executives and clients growing up. Therefore, besides the fact that polish is very arbitrary and can lead to a monoculture it can certainly lead to inequality as well.

In conclusion, I found this book to be great at illustrating all the short comings of the interviewing process at Elite Professional Service firms and that it unfortunately leads to more inequality in society. Furthermore, as Rivera suggests, firms needs to widen their interviewing scope not just for the sake of candidates, but even for the sake of hiring smarter and more competent students. They must stress the importance of having grades over institutional prestige and culture extra-circulars. In addition, to handing the interviewing process to more professional interviewers who can structure the interviews and detach themselves from the arbitrary metrics currently used.

References, Further Reading:

Old Boys Network

https://en.wikipedia.org/wiki/Old_boy_network

Pedigree in Tech

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

Insight: In the Silicon Valley start-up world, pedigree counts – https://www.reuters.com/article/us-usa-startup-connections-insight-idUSBRE98B15U20130912

Does the startup world have a Pedigree problem – https://qz.com/work/1695042/does-the-startup-world-have-a-pedigree-problem

The 10000 hours rule

https://www.theguardian.com/science/2019/aug/21/practice-does-not-always-make-perfect-violinists-10000-hour-rule

https://www.vox.com/science-and-health/2019/8/23/20828597/the-10000-hour-rule-debunked

Can ChatGPT accelerate No-Ops to Replace DevOps in EarlyStage Startups?

By [email protected] | June 11, 2023 | Comments 0 Comment

Background: I work with multiple CTOs and Heads of Engineering of early-stage startups to help them set up their engineering orgs, review their product architecture, help them prioritise their hiring etc. I also help multiple engineering leaders via Plato. Recently, there have been too many questions on whether can I use ChatGPT for this or that, but the most interesting one among these is “Can ChatGPT accelerate No-Ops to Replace DevOps?”. I have answered that multiple times in verbatim. But thought that writing it down will help me with two things, I can point them to the URL and I can also clearly structure my thoughts on this. So this is an attempt at that.

Glossary First:

DevOps:

For the uninitiated, DevOps is a software development methodology that emphasizes collaboration and communication between developers and operations teams. The goal of DevOps is to increase the speed and quality of software delivery while reducing errors and downtime. DevOps engineers are responsible for the design, development, and delivery of software applications, as well as the management and maintenance of the underlying infrastructure including the pipelines, quality assurance automation etc.

No-ops:

No-ops, on the other hand, is a philosophy that aims to automate and simplify the operations side of software development. The goal of no-ops is to eliminate the need for manual intervention in the deployment and maintenance of applications, freeing up time for developers to focus on creating new features and fixing bugs.

ChatGPT:

ChatGPT is a language model developed by OpenAI that has the potential to revolutionize the way we interact with technology. It can perform a wide range of tasks, from answering questions to generating text and even a rudimentary bit of coding. In the context of DevOps, ChatGPT could be used to automate many of the manual tasks that DevOps engineers currently perform, such as infrastructure management, deployment, and monitoring.

Now, The question: Can ChatGPT accelerate No-Ops to Replace DevOps?

ChatGPT (or any of the other generative AIs) has the potential to automate many of the manual tasks performed by DevOps teams, it could potentially replace the most mundane tasks that DevOps perform pretty soon. So, before writing this piece, I wanted to actually put my understanding to test.

I had to use Bard for this experiment, but I do not think there is going to be much of a difference in the outcomes.

Experiment 1: Beginner-Level Task

Writing a simple Autoscaling script to scale as per CPU and memory utilisation.

Simple AutoScaling Script, written by Bard

Experiment 2: Intermediate-Level Task

Creation of a new VPC with 3 autoscaling groups of EC2 and 1 NAT gateway and VPC peering.

Results were mixed.

Though Bard did give information that this can be tweaked, there was one major gap between the ask and the outcome. The NAT gateway was supposed to be the single point of ingress/egress, whereas the script is entirely different.

Assume an early-stage startup that gets used to the early success of Generative AI to preempt the DevOps culture, at some point the AI won’t have the context of what all is in your infrastructure and you could end up misfiring things.

My submission is, ChatGPT or Bard or any Generative can be super helpful for a good DevOps engineer and cannot replace her/him anytime soon. In military parlance, certain materiels are termed Force Multipliers. But, they themselves cannot be the force! (Aircraft carriers or Tanker aircraft are the prime example)

Why do I believe so?

There are several reasons for this:

Human creativity: Despite its advanced capabilities, ChatGPT is just another AI model and lacks the creativity and innovation that a human DevOps engineer brings to the table. DevOps engineers can think outside the box and find new and innovative solutions to “Business” problems, whereas ChatGPT operates within the constraints of its programming and is simply solving the “Constraints” for that technical problem.
Human oversight: While ChatGPT can automate many tasks, it still requires human oversight to ensure that everything is running smoothly. DevOps play a crucial role in monitoring and troubleshooting any issues that may arise during the deployment and maintenance of applications.
Complexity: Many DevOps tasks are complex (or at the very least, the DevOps teams would want us to believe that) and require a deep understanding of the underlying infrastructure and applications. ChatGPT does not yet have the capability to perform these tasks at the same level of expertise as a human.
Customization: Every organization has unique requirements for its development and deployment process. ChatGPT may not be able to accommodate these specific needs, whereas DevOps engineers can tailor the process to meet the non-stated requirements and organisational and platform context
Responsibility: DevOps engineers are ultimately responsible for ensuring the success of the development and deployment process. While ChatGPT can assist in automating tasks, it is not capable of assuming full responsibility for the outcome.

In conclusion, while ChatGPT has the potential to automate many manual tasks performed by DevOps engineers, it is unlikely to replace DevOps entirely in the near future. The role of DevOps will continue to be important in ensuring the smooth deployment and maintenance of software applications, while ChatGPT can assist in automating certain tasks and increasing efficiency. Ultimately, the goal of both DevOps and no-ops is to increase the speed and quality of software delivery, and the use of ChatGPT in DevOps can play a significant role in achieving this goal.

References:

https://humanitec.com/whitepapers/devops-benchmarking-study-2023

The Paradox of Superhero Leadership

By [email protected] | February 5, 2023 | Comments 1 comment

Disclaimer: I have immense regard for Elon Musk, so much so, I have gifted Ashlee Vance’s book on the Paypal Mafia boss to multiple people. I have even compared him to the fictional Peter Weyland in my discussions with fellow nerds. But this article is not about the trailblazing leader who sows the seeds of interplanetary exploration/colonisation. It is more about the God Complex and a reflection of multiple things that come with it which may or may not be positive. I have written about the superhero style of leadership earlier as well and briefly, touched on it in a previous article, albeit on a much smaller scale.

Introduction:

Off lately, there is a view, it is called the “superhero” theory of leadership. In which, the individual vision, charisma, and brilliance of a CEO “makes or breaks” a company. This view is absolutely dangerous — not because CEOs don’t matter or that smarts and vision don’t help. It’s dangerous because of what it ignores. Great leadership takes both mundane “management” skills and highly specialised “Domain-specific” ones. The most effective leaders have the knowledge and softer aspects that are specific to their company and industry that allow them to not just motivate, but also drive other people in the organization to do what’s necessary to succeed.

It’s been a hell of a time for the last two or three months, for news reporters, management consultants, professors in Ivy league & Red Bricks and the new age “gurus” and “influencers”. The fiasco with FTX is an unbelievable story of lapse of controls, comparable to Enron, Daewoo and Satyam. Which supposedly is an understatement as per the new executive appointed to steward it through bankruptcy. Elon Musk’s bid to takeover Twitter and the ensuing drama is equally newsworthy, not sure how much popcorn was sold to watch this drama. And finally, the end arrived for the Theranos story, with Elizabeth Holmes and Sunny Balwani sentenced to 11 years in prison.

All of these stories have something in common, they combine a very flashy leadership style with a blatant disregard for actual management practices.

The issues at FTX are too numerous to even list as a bullet point in this article, but the crux of the problem is simple. It is a complete lack of checks and balances. Plain vanilla management or accounting is not something that gets you on the cover of Fortune or The Economist or Economic Times, but oversight of a company’s activities and checking on finances is the trait of good management and leadership. At FTX, it seems to have been completely ignored. How could the company grow so much in the absence of any basic management systems? The sad part is investors and customers were also fooled by those flamboyant “leadership” (remember Nikola ?)

The trajectory of Musk’s Twitter takeover is even more disturbing. Again, it is a story of a CEO who is proud of his blatant disregard for the basics of management and an almost untainted faith in his “superpowers” and the unchallenged position of his leadership and intellect, also called The God Complex.

At the reinvented Twitter under Musk, there seems to be no regard for basic HR practices as well. Musk has massive challenges to rally and retain his employees; even assuming he wants to “rightsize” by encouraging resignations, his eccentrics may have pushed even the folks whom he intended to retain.

What can we learn from these companies? They are both ongoing, but thus far it seems that these firms have fallen victim to an all too popular belief that “superhero” leadership trumps boring management.

This is wrong, in at least two ways.

First, there is enough evidence that boring management matters and it is a source of competitive advantage for companies that take it seriously. A 2012 research by HBR has shown that management practices vary quite a lot within industries and around the world — and that companies with good management are significantly more profitable. Secondary research has confirmed that good management improves firms’ performance.

What is good management? There’s no single, comprehensive answer. But it looks like this in practice, target-setting, rewards, and monitoring. Well-managed companies set reasonable, strategic goals; set their staff up to contribute to them; and measure their progress.

Call it boring or mundane if you like — it is good business.

A major gap in the superhero theory is that it super simplifies what good leadership is. Consider the current debate over Elon Musk. To his fans, Musk’s success at Tesla, SpaceX and PayPal makes him a great leader. To his critics, the maelstrom at Twitter proves the opposite. That’s too binary, black or white. The reality is a million shades of Grey in between Black and White! Prior research does show that CEOs do matter to a company’s success, but their contribution is about more than just grand vision and raw intellect. And how much of what depends very much on the organisational backdrop.

We think of a leader’s contribution to a company along three dimensions.

The superhero narrative simplifies the entire facet of leadership on vertical differentiation, because it’s fun & easy to argue over and write cover stories about. The other two factors — Horizontal differentiation and Force Multiplier (ability to influence an organization) — are much harder to discuss and not that fun to write about.

But, when an entire generation has grown upon SuperHero movies where it is the Vision, Grit and perseverance of the Hero that saves the day, it is too hard to think in other ways. Even in pop culture, I come from a generation, where the hero gets battered and relies on the collaboration and cooperation of his friends and partners to make it out. Then, there are the “Wise old men” or the occasional woman, who gives some much-needed advice and insights.

How would this three-dimensional assessment differ from the superhero story when it comes to Elon Musk and Twitter? It would complicate the debate that both his fans and his critics seem to be having and instead would go through the three factors mentioned above. Rather than arguing solely about whether Musk is a good CEO in general, we can ask whether he has the skills and experience necessary for running a social media platform — and whether he’ll be able to motivate and manage the team that’s in place.

It’s perfectly reasonable to think, for example, that Musk is an above-average CEO, not particularly well suited to running a social media platform, whose behaviour in the run-up to his Twitter takeover ensured he would not be able to influence the people that he needed to in order to succeed.

This view of leadership is harder to put on magazine covers, and it is therefore often forgotten. But ignoring the complex relationship between leaders and their organizations is bad for investors, consumers, and ultimately for managers and CEOs, too.

References:

1, Super Hero Leadership – https://www.linkedin.com/pulse/superhero-syndrome-leadership-what-good-thing-luke-lynch/?trk=public_profile_article_view

https://www.kingsfund.org.uk/publications/heroic-leadership

https://www.fearlessculture.design/blog-posts/leaders-must-stop-being-superheroes

2, Martyr Syndrome – https://nocturnalknight.co/2022/08/a-tech-lead-writing-code-is-a-disservice-to-the-company/

http://deeelliottconsulting.com/system/files/Leadership%20and%20Martyrs%20in%20the%20Workplace.pdf

3, FTX fiasco – https://www.forbes.com/sites/amyfeldman/2022/11/22/with-a-new-ceo-an-adult-has-arrived-to-clean-up-the-ftx-mess/

https://www.thestreet.com/investing/cryptocurrency/timeline-of-cryptocurrency-exchange-ftxs-epic-collapse

4, Theranos Collapse- https://www.theguardian.com/technology/2022/dec/07/former-theranos-exec-sunny-balwani-prison-sentence

5, Does Management really work – https://hbr.org/2012/11/does-management-really-work

6, The effect of Managers in a Firm – https://academic.oup.com/qje/article-abstract/118/4/1169/1925095?redirectedFrom=fulltext

How to measure Engineering Productivity?

By [email protected] | November 27, 2022 | Comments 0 Comment

The fact that you clicked on this article tells me that you are leading/heading a Team, group or an entire Engineering function and most likely a fast-paced startup. Assume the following,

It was a regular weekday, and your CEO/CTO asked the most intriguing question.

Do we measure Engineering Productivity? How do we fare? What can we do to improve it?

Well, if your boss’s name is not Elon Musk or if you do not work for Twitter, you can still be saved. Go on and read through. I know it is a long read.

What is Engineering Productivity?

As with anything you’re trying to improve, it starts with measuring the right data. So, you can actually track the right metrics. This data will form the basis of your analysis and baseline. I strongly recommend you don’t change anything about your current engineering process before you can collect sex weeks’ worth of data about your processes. If you start working on processes, you could end up with a Survivorship Basis.

You should have sufficient historical data to make comparisons. On top of that, most teams work in sprints of two weeks, so six weeks of data allows you to collect data for at least three different sprints. This will give you the allowances for any spikes and eliminate any unusual stress or slack on the execution.

Next, you should make gradual changes to the engineering process to see what improves or impedes the value delivery. It’s ideal to only implement one change at a time, so you can see the effect of each change, with all other things being equal. (it never is :D)

For example, if your engineering squads suffer from significant technical debt, you may want to build an additional stub related to feature completion. Every time an engineer completes a new feature, they must document the new feature. This could mean describing the feature, how is it built, what are the outcomes, how it interacts with other functions and the reasoning behind the design decisions.

By continuously measuring engineering productivity metrics, you can determine if this change has positively impacted the developers’ productivity.

How Is Engineering Productivity Measured?

There are potentially 100s of metrics you can measure for an Engineering Org. Here are four key metrics that will help you to get started with measuring engineering productivity. And I have consciously excluded the Sprint Velocity.

4 Prime Directives of Engineering Metrics

1. The One Metrics to rule them all metrics – Cycle Time

Software development cycle time measures the amount of time from work started to work delivered. It is a metric “borrowed” from lean manufacturing, and it is one of the most important metrics for software development teams. In plain speak, cycle time measures the amount of time from the first commit to production release.

2. The Oracle of an Engineering Leader – Release Frequency

You should measure how often you deploy new changes to your customers (production). In addition, you can track deployments to various branches/instances, such as feature branches, hotfix branches, or QA branches. This data would show you how long it takes for a feature/fix to move through the different development stages. In addition, the Release Frequency reflects the throughput of your team. It’s a good stand-in replacement for Agile Velocity, so you don’t spook your Engineers and you are not blind as well.

3. The Guardrail – Number of Bugs

You should definitely track the number of bugs that your team has to resolve within 2 sprints of releasing a feature. This metric helps you to understand the quality of your code better. Higher-quality code should display fewer bugs after feature deployment.

While there are derivative and more evolved metrics like Defect Density, Mean Time to Detect (MTtD), Mean Time to Resolve (MTrR) and Code coverage, those onces makes sense after you’ve taken stock of and address the prime metric “ No: of Bugs” first.

If you want a more detailed list, methodology of QA metrics, refer the links given below.

4. What is your “Blocker” – Review to Merge Time (RTMT)

This may look like a zoom-in on “Cycle time” metric we discussed earlier. But, in fact it is very different. In fact, it is an interesting metric suggested by GitLab’s development handbook.

You should measure the time between asking for a pull request (PR) review and merging the PR. Ideally, you want to reduce the time a feature spends in the review state (or pending review state). A high RTMT prevents developers from progressing while they wait for feedback and encourages context-switching between different issues/features.

Arguably, Context-Switching is the highest productivity killer and should be avoided as much as possible.

So, why would you measure all these engineering productivity metrics?

Why Is Measuring Engineering Productivity Important?

When you’re a “fast-growing startup”, it’s important to keep an eye on engineering productivity. It happens that these startups favour growth through feature delivery at the cost of effectively scaling the engineering team and ensuring the team’s efficiency.

I hear your question.
But, why does my CEO/VP/MD not understand?
Answer is simple
Assume you have to manage multiple VP’s expectations and outcomes (Sales, Marketing, Support etc), Company’s OKRs, and investors (or) board, will you have more time to dedicate to Engineering Productivity?

In these cases, technical debt can quickly grow, which will slowly kill your team’s productivity. Technical debt can have many negative consequences:

More bugs for your team to fix
Lower code quality—not only bugs but also worse code design
Harder to debug code
Scalability issues
A decline in overall happiness and job satisfaction

To avoid all of these scenarios, you should measure the engineering team’s efficiency and avoid technical debt buildup. Avoiding these problems before they occur is an excellent Occam’s razor. But addressing them head-on will have a significant impact on your organisation, both materially and culturally.

In addition to preventing your team’s productivity from going down, the engineering productivity approach allows you to experiment with various approaches to try and improve throughput & efficiency.

So, the goal is to improve the engineering process itself. For example, introducing new tools or applying new techniques. Next, you can measure the impact of these changes on your team’s productivity.

In the next part, I will write down on how can measurement improve engineering productivity, Stay Tuned!

References:

Survivorship Bias.
1. https://www.masterclass.com/articles/survivorship-bias
2. https://en.wikipedia.org/wiki/Survivorship_bias
Cycle Time
1. https://tulip.co/blog/cycle-vs-lead-vs-takt
Release Frequency
1. https://community.atlassian.com/t5/DevOps-articles/Why-should-we-start-measuring-the-Release-Frequency/ba-p/1786430
Detailed QA Metrics to ponder (in addition to No: of bugs)
1. https://reqtest.com/agile-blog/agile-testing-metrics/
Review to Merge Time
1. https://about.gitlab.com/handbook/engineering/development/performance-indicators/#review-to-merge-time-rtmt
Context Switching
1. https://pacohq.com/blog/guide/the-high-price-of-context-switching-for-developers/

Why Engineers Hate your “Boiler Plate” Job Descriptions?

By [email protected] | August 21, 2022 | Comments 0 Comment

How to Attract the most relevant applicants with great job postings

One of the main problems in SaaS/Software engineering hiring is the way job descriptions are written. While I knew this for some time (read years) The problem is, I was too lazy to change anything about it! That is until recently, one of the candidates I was interviewing for an Engineering Manager Role said this in our introductory call,

Me: Hope you’ve had a discussion with Ms.ABC (our HR) regarding the Roles and Responsibilities. If there are questions on it I can answer them, or we can get into the agenda.

Candidate: Yes I had a discussion with Ms. ABC. But, quite frankly it was your boilerplate JD. I’d actually want to understand what exactly I’d be doing. What will I be in charge of? What will I move?

Needless to say, I spent the next ~30 minutes walking through the current team structure, where he’d come in, what will he own, what the growth trajectory looks like etc. Ultimately, we did 2 more calls before both of us were satisfied that there are mutual synergies and went ahead. It made me reevaluate all of our Job Descriptions over the weekend and rewrote almost half of them to include factual details on projects, outcomes expected, tools available, glimpse of growth among other things.

After this, I asked the HR to send this “revised” JD to the candidates once again.

And the result was visible from Monday!

Either candidates that the HR thought super suited started dropping voluntarily from the process or candidates started expressing interest, doing more research on our stack, infra, product proposition and competitor benchmarking, before the call. Some even did a cold reach-out on Linkedin.

So, I wanted to share the small titbit here.

Why General Descriptions Don’t work?

Most Job descriptions barely resemble “specifications” at all, but feel more like generic stubs. Sort of like the equivalent of shopping for a car with as much details as “red and goes fast” or “black and built to last.”

It leaves too much open to the imagination for it to be a successful criterion to enable fitment. With criteria as broad as this you’ll end up spending an inordinate amount of time executing the search, since so many things appear to be a match. For me, Red and goes fast is always a 1971 Ford Mustang, for you it could be a 1998 Ferrari 365.

A Red Ford Mustang & a Ferrari 365, What do you Fancy?

A Black Dodge Ram and Jeep Cherokee, What do you Prefer?

The truth is that statements like the above — or its equivalent in engineering hiring — “Get me a backed dev with OOPS in Python/Java/Go with 5 years experience” — guarantee a similarly frustrating shopping experience. You’ve made it needlessly difficult for yourself and your HR/TA team to identify the specific talent you want. In this trite example you’ve indicated that you’re looking for a mid-level engineer that knows OOPS, but that basically includes everyone that ever graduated with a CS degree in the past 5 (to 10?) years. Surprisingly, many job “specifications” we see contain rarely any more info. These are the “Boiler Plate” Job Descriptions.

How did we find ourselves in this mess?

I understand why hiring managers do this. Sometimes they’re not exactly sure what they want — after all, it takes real time and effort to work out the specific vision for the role. But instead of acknowledging this and then solving the real problem (their own laziness), they delegate the JD writing to their Team/HR and it turns into generic tech JD. But the hiring manager is unfazed — “I’ll know the right candidate when I see them,” they say. Really? It could be true in some instances. Sometimes, we start with a Backend developer, then we come across a candidate with experience in building a full pipeline or a payment system. Then we expand the role to cover wider scope and evaluate against it. But generally, How will they know the right candidate if they can’t write down specifically what the candidate looks like?

Another reason for generic job specs is because a hiring manager is recruiting in a talent-constrained market (sound familiar?), and it feels like a smart move to cast as wide of a net as possible. Theoretically, one should be able to get more candidates into the top of the funnel this way, right?

Perhaps. Theoretically. But in my experience, this approach usually, and utterly, backfires. Here’s why:

Boiler Plate Job Descriptionsaren’t designed to appeal to any engineer in particular

In the current job market, engineers are faced with a wide variety of options from some amazing established companies and lots of seemingly “sexy” startups. (after “the great resignation”)

You need to take your opportunityto stand out! The more specific you are about the challenges a specific engineer will get to work in a specific role, the more traction you’ll get with (the right) candidates.

The idea is to make an engineer excited when you describe what they will “Get to do” in the first 12-15 months in the role.

Be very specific,

Talk about the product/modules they will own/drive/be part of,
Talk about the outcomes and metrics they will own and drive,
Talk about the toolchains & frameworks they’ll use (or get to choose),
Talk about What’s hard/challenging about the role, How are they a great fit.
The more details you can squeeze into the spec to help them visualize their role and the projects they’ll be working on the better.

Boiler Plate Job Descriptions don’t arm others to help you

Another bad thing about generic JD is that they don’t help others help you. Think of how much reach could you get by using everyone in your network as a recruiter. But in today’s scenario, “everyone else” is already asking them if they know any Python Engineers or React Developers or Go Engineers. Why would they help you? Because you’ve taken the time to get specific about what you want? Maybe.

Take a look at the following Job Description. Anyone in software engineering who had some deployment, infra-planning & communication seems to be a candidate for the role.

I recently got a request from a founder friend of mine to refer a Sr.Tech Lead/Engineering Manager for an early-stage startup. When I saw the JD, it was so generic it did not even have the primary stack on it. Assume sharing it from your handle. I politely declined to share it and asked for some more information and said will come back once he shares. (I believe he is very busy and hence hasn’t come back)

The bottomline is, Make them want to help you — give them a JD that’s so amazing, well-written, specific, (even entertaining) — that they can’t help but pass it on, post it, tell their friends about it, etc. If you make it stand out — you’ll get more attention from the folks that can help because you’ll arm them with something interesting & effective that they can use to reach out to their network.

Boiler Plate Job Descriptions don’t enable you to know what success looks like

This is a very simple point — see above — if you can’t explain what the ideal candidate looks like, how will you know when you’ve found them? The JD shared by my friend looks as vague as this.

Actually, his company was looking for a guy who could not just do Infrastructure Architecture. They wanted someone who has architected/built a cloud native SaaS application. His team has built the application and has no idea how to convert it to truly cloud native format to scale without breaking the bank!

The main idea here is about not being willing to settle for less. I realise the market is tough right now, and maybe you’ll need to make compromises. But do you want to start at the wrong end of the pool? When you go out the door with a generic description, you preemptively give up the battle. If you need to settle — fine! — but know exactly what points you’re compromising on.

The larger problem is that if you don’t know what the best candidate really looks like then the other people involved in making a decision likely don’t know what s/he looks like either. A well-defined, specific description of the role enables everyone involved in the interviewing and hiring process to be on the same proverbial page.

Now go get started!

Fixing your job descriptions will take some work(as I found out). To get to specifics, you’ll need to dig in and make additional efforts. You might also need to do some retraining in your organization and teach others these principles, too.

But when you get through the hard work, your postings will turn into valuable weapons that will,

a.) appeal to the engineers you want to reach,

b.) enable others to help you expand your outreach, and

c.) get your hiring team on the same page to quickly come to the right decision.

If you’re curious to see what roles we currently hire for, we have a lot of openings in Product, Design and Engineering:

It ranges from Kubernetes Architect, React Native Mobile Dev, Sr.Backend Dev, Tech Lead-Mobile Technologies, Engineering Managers, Associate Product managers, Product Managers etc.

More details can be had at https://angel.co/company/itilite-1/jobs or you can ping me 🙂

Do you really need a Product Manager for a successful Product?

By [email protected] | August 15, 2022 | Comments 0 Comment

This post is a summary of a series of “Mentoring” and “Advisory” calls I did with some early stage startups, over the past 6 months. Most of the time, one of the founder ideates, one builds/leads the build. But, they want to go fast and think they need a Product Manager. Unfortunately, most of them don’t need a Product Manager. If you are at a similar juncture, read on to find out more..

The title is a controversial question, I know!

The State of Product Management:

Off lately, Product Managers have to wear too many hats, leaving the role vague and blurring the boundaries of their area of responsibility. This ultimately leads to diminishing the value of the product manager’s core functions. Product Management is a strategic, cross-functional, front-line role that brings great value to the product and business.

But, it commonly gets abused by many fast-paced organisations expecting product managers to fill in the gaps in various disciplines. This may be process, pricing, unit-economics, partnerships, product-marketing to name a few. They can definitely do that due to their broad professional background.

Admittedly, product managers do have a broad background, otherwise they would have a hard time to be able to effectively collaborate with the stakeholders, lead the product and make the informed decisions. But this definitely should not end up with the product managers becoming de-facto “deciders” or “doers” originally intended to be done by other roles in other functions.

How do you decide if you need a Product Manager or Not?

Like any problem, there are two approaches, if an intellectual debate is more to your taste, continue reading on. If it is more of a rational “doer” approach, head straight down to it.

Intellectual Approach

Ask yourselves some questions:

If you are a founder or a leader or a decision maker, before hiring a Product Manager, question yourself as to your expectations from the product manager.

Think hard on what you want them to do:

What do you want your new product manager to change/fix in your organization? What is it that you are unable to do?
Do you not already have the in-house expertise that would help you address the current issues?

If you are still unsure about whether or not you need a product manager “in the house”,

I recommend that you go through this checklist and answer Yes/No to each of its questions:

Do you have a vision for your product? Do you believe it is aligned with the market needs?
Are you sure you are building the right product — the one that delivers value to your target audience?
Do you have a direction for your product? A long-term and a short-term roadmap?
Till now, have you been able to execute your roadmap without major distractions?
Are you capable of maintaining the strategic focus across all levels of the organization?
Do you know your competitors and what they have on the game? Proposition, not features.
Do you have an established feedback loop with your clients? (Not the feature request types)
Do you mostly base your decisions on evidence/data?
Do you find it easy to say “No” to various stakeholders from various functions while hearing their “suggestions” and “inputs” and explain them why what they think is not the “most” right thing?

If you answered “No” to more than 4 questions, you probably need a Product Manager, No doubt in that.

But the reality is, that hiring a highly capable Product Manager won’t magically change the DNA of your organisation. I have seen multiple orgs regress into a worser situation than before. Because, the person responsibl has delegated the product decisions to that Product manager with a shiny belt, without enabling/empowering him/her.

The result

Rational Approach

If you’re a CEO, founder, or senior leader considering hiring a PM, check this list and see if you need one. Lets play a guess and eliminate game.

If you can see your organisation is reflected in this article, don’t bother hiring a PM — save some money and hire a cheaper role. You would also spare a PM some misery.

Don’t bother hiring a PM…

If you have a fixed idea of what to build

You already know what you want to build, you just need somebody to build it. You’ve hired some engineers. You need somebody to gather the requirements from you and the team, and maybe manage the back-and-forth of different requirements from many stakeholders. This person then passes the requirements along to the engineers and makes sure they deliver on time.

You need a Project Manager, not a Product Manager.

If your Sales team or clients are dictating what to build

You have a handful of big clients and you’re ready to bend over backwards to deliver what they need, including building custom features. Your Sales team knows best what to build, surely, as they’re the ones talking to the customers all the time. Now it’s just a matter of writing the stories and prioritising them.

You need a Delivery Manager, not a Product Manager

If they won’t have access to your customers

You have some very-important-people as customers and their time is precious. You don’t want the new person you just hired to talk to them directly — may be they will say something untoward?

I don’t know what you need, but you certainly don’t need a Product Manager.

If you’re not ready to delegate authority

You know that product managers should be given a problem to solve, not a feature to build. Heck, you were probably a Product person yourself, who has now set up your own startup. You have the vision and the strategy and you know exactly how to get there…

What’s left for the Product Managers to do, then? Maybe hire an Engineering Manager or a Tech Lead?

If you see technology as a support function

An easy way to assess this: How much of your company budget is dedicated for product/technology/innovation? If you’re not willing to invest significant resources to staff the product/technology team properly, they’ll be left firefighting all year long.

Don’t hire a Product Manager — yet. Assess how you see technology plays a role in your company’s vision. Set aside a proper budget, hire a strong CTO or CPO, and let them build their team. Only do that if you’re willing to listen to them though — or don’t bother doing it at all.

In Sum and summary, Hire a Product Manager only if you believe you can delegate authority, and can come to a rational decision based on data. If not, hire a Project Manager, Engineering Manager or any of the other roles.

A Tech Lead writing code is a disservice to the company.

By [email protected] | August 7, 2022 | Comments 0 Comment

You have been coding your whole life or at least most of your professional life. Recently, you have been promoted/designated or as a Lead Engineer or a Tech Lead. Does anything change for you?

Should you stop coding?

People generally say, hell no!

And why should you now?

You like it;
You enjoy it and probably
really good at it too.

But then you start leading a team, which means that everything should change or at the minimum, something should change Or shouldn’t?

It’s an eternal question for every engineering manager. I have tried to answer it all along my career and

The hardest thing is to understand that you are not “just a” developer anymore.

I know, the above statement is controversial with multiple of my readers.

Most of you are now in a role with,

different responsibilities,
different daily schedules, and
tasks that involve different mental processes.

And you are most likely trying to combine two things at this time.

You’re trying to be a good developer (that you used to be).
You’re also trying to act as a “Coordinator” “Communicator” and also “Manage” things

I know, your designation/title says Tech “Lead” or “Lead” Engineer and not Engineering Manager. But, in most organisations, a TL is looked upon as an EM in waiting (For more insight on career tracks for a TL – Check out my previous article on Engineering Leadership on Startups )

And working two jobs may often lead to early burning out and, frankly, not being any good in either of them.

I will take two very probable examples here.

Case 1: You are a Lead and you want to own a particular piece of code rewrite, which is giving a lot of concurrency nightmares to both the product support and your on-call teams. Most design/debug and development tasks require high concentration and focus, which contradicts the very nature of the team leader’s work. Multiple planned meetings, calls, messages — a lead needs to be on alert. It’s tough to consider all the edge cases when your slack/hangout/teams is buzzing all the time.

Another essential element is most of these buzzing & pinging can be controlled if your team is good at Asynchronous Communication. (I will write more about it in a future article)

Case 2: You are a Lead, driving a new subscription module for your latest product. There are simply so many stakeholders, your PM, Payments team, external partner/vendor, Infra team etc. It will be hard to be prepared to answer your teammates’ or vendors or customers’ questions if all you can think about is the efficiency of that function you just wrote.

Time Share:

Another thing is that spending a lot of time on development gives you little time to do your actual job as a lead/manager. And your job is managing other people. Though you will probably make time for your primary duties — assigning tasks, making estimations, validating designs, communicating with the stakeholder — you will miss out on all the other “noncrucial” parts of your job.

You can get so invested in a feature that you will miss some critical signs of your employees becoming demotivated to do their work, tired, or less happy. And, as you are busy, you become less innovative. Who will come up with a new architecture for the 3-year-old service? Most certainly not you, since you are too deep in the code.

Anti-Growth

Minefields you’d inadvertently trigger are either the Martyr Effect or the Hero Syndrome (Think Bruce Wayne or Tony Stark). On the first & second one, You’d always take the toughest part of the code or the most interesting part of the code, respectively. Either way, you’d be creating a team who’d be ill-prepared to take up challenges on their own or ill-equipped.

But what if I do not want to give up coding?

It may so happen that plain management isn’t your path. So, from here on, you may not enjoy what the role has to offer. Being a Team Lead/EM is all about people; being a Principal Engineer (or staff engineer or architect) is about code. If programming is critical for you and brings you more joy, you may be more suited for a Technical Leader role. So choose wisely.

But as a Team Lead, you are still most welcome to join code reviews and help your teammates with challenging coding problems if you want to.

Consult. Guide. Assist. Communicate
This is going to be your Motto.

And of course, You should definitely continue to code in other “Non-paying” parts of your job. Start automating your units, create boiler plates, write smaller, niche, critical elements of your system.

How to select SSO Standard for your SaaS Application.

By [email protected] | May 1, 2022 | Comments 0 Comment

For anyone developing any application on the cloud, the major concern is always how is security implemented. Typically, you start with an authentication system viz. Usernames & Passwords. As your application grows in size of use cases and adoption, you’ll soon find a necessity to improve your security posture, these could range from MFA, Federated Identity management and finally authorisation. You now have customers who ask if you can support their AD authorisation or OneLogin or Okta etc.

This is when you’ll think about implementing a Single-Sign-On. But, the choice of how to keep data and identities secure begins much earlier for software architects and developers: selecting the standard that should be used to keep federated identities safe. This will involve two things, architecting an authorisation system – could be a separate service or bound with your application – this choice is critical to how you can grow as an organisation.

Architecture Choice:

If you choose to integrate it with your main product and 2 months later your board directs you to develop a new offering, you’ll end up doing it all over again. On the contrary, if you’re not going to pivot to any new business line, the additional time you will incur in building an external “Accounts service” will be a tax on the GTM.

Standards Choice:

IT Administrators and Security Architects must first choose the protocol or framework to use to maintain federated identity, or the mechanism of connecting a person’s electronic identity and attributes, safe while designing a plan to keep data and identities secure.

A Single Sign-On (SSO) account has the advantage of allowing employees to log in once to an application or network and not have to log in to several apps or networks during the workday. While this is beneficial to employees in terms of increasing productivity by eliminating the need to remember several passwords, it is also beneficial to IT and Security functions. The Identity and Access Management (IAM) platform responsible for maintaining employees’ credentials can assist make it more manageable by registering fewer passwords in the system.

It is, however, not an easy choice. Security Assertion Markup Language (SAML), OpenID, and open authorization are the leading candidates in the federation process (OAuth). Let’s take a closer look at these technologies and determine when SAML, OAuth, and OpenID should be used.

What is Single Sign-On (SSO)?

SSO (Single Sign-On) is an authentication method that allows apps to validate users by using other trustworthy apps. Single sign-on allows a user to use a single ID and password to log into several applications.

SSO is an important part of an Identity and Access Management (IAM) platform for managing access. User identity verification is crucial for establishing what permissions a user will have.

SSO Standards

SAML

SAML is a protocol that allows an Identity Provider (IdP) to send a user’s credentials to a service provider for authentication and authorization. SAML allows for Single Sign-On (SSO) and streamlines password management. It is beneficial to businesses because employees are using an increasing number of applications to complete their tasks.

Keeping track of passwords for hundreds of programs used by hundreds, if not thousands, of employees can be difficult. SAML comes to the rescue by providing a single sign-on standard for businesses.

OAuth

OAuth 2.0 is a secure authorization standard. It allows secure delegated access by providing third-party services with access tokens rather than exposing user credentials. It does not, however, authenticate; it just authorizes.

You’ve probably used OAuth 2.0 if you’ve ever signed up for a new app and consented to allow it automatically source fresh contacts from Facebook or your phone contacts. This standard ensures that delegated access is secure. This means that a program can operate on behalf of a user and access resources from a server without the user needing to provide their credentials. This is accomplished by allowing the Identity Provider (IdP) to issue tokens to third-party apps with the user’s permission.

OpenID

The OpenID Connect (OIDC) standard is used for authentication. OIDC is used by identity providers (those who generate and administer identities) so that users can log in with their IdP first and then access applications without having to re-enter their credentials.

This authentication option is recognizable if you’ve used your Google account to sign in to apps like YouTube or Facebook to log into an online shopping cart. Organizations use OpenID Connect to authenticate users, and it is an open standard. This is used by IdPs so that users can sign in to the IdP and then use their sign-in information to access other websites and apps without having to log in or disclose their sign-in information.

SAML VS OAuth VS OpenID

OAuth 2.0 is a framework for regulating authorization to a protected resource, such as a program or a set of files, whereas OpenID Connect and SAML are both federated authentication industry standards. As a result, OAuth 2.0 is used in quite different situations than the other two protocols, and it can be used in conjunction with either OpenID Connect or SAML.

OpenID Connect is based on the OAuth 2.0 protocol and uses an ID token, which is a JSON Web Token (JWT) that standardizes areas where OAuth 2.0 provides for flexibility, such as scopes and endpoint discovery. It depends on user authentication and is often used to make user logins easier on consumer websites and mobile apps.

Unlike JWT, SAML does not rely on OAuth and instead relies on a message exchange to authenticate in the XML SAML format. It’s more commonly used in enterprise settings to allow users to log in to several applications with a single password.

Final Thoughts

As technology advances and systems become more interconnected, federated identification becomes increasingly useful since it is more convenient for users. It saves them time by reducing the number of accounts and passwords they have to remember, but it raises some security concerns.

SAML has one feature that OAuth2 lacks: the SAML token contains the user identity information (because of signing). With OAuth2, you don’t get that out of the box, and instead, the Resource Server needs to make an additional round trip to validate the token with the Authorization Server.

On the other hand, with OAuth2 you can invalidate an access token on the Authorization Server, and disable it from further access to the Resource Server.

SAML provides a simpler and more standardized solution which covers all of our current and projected needs at ITILITE and avoids the use of workarounds for interoperability with native applications.