Responding to concerns as a people manager

You are the people manager for a team, and a team member comes to you with a concern. How should you approach it? I have been in this situation multiple times, and have admittedly made some wrong turns. After some corrections and learning, here is what seems to work well for me (although YMMV). If you like lists, here is a snapshot of the path I take.

  1. Listen
  2. Empathize
  3. Don’t take notes
  4. Descend into the particular
  5. Check with others
  6. Socialize, if the issue is common
  7. DO NOT become an apologist for status quo

Note that this doesn’t talk about the resolution for the issue. That is very specific to the issue at hand. What I have is more of an approach to understanding the issue in a manner that is respectful of the stakeholders. With that disclaimer, let’s unpack each of those bullet points.

Continue reading “Responding to concerns as a people manager” →

Git may not be the best for SaaS companies

Yes, I realize that this is going to be pretty controversial 🙂 Let’s dive in, shall we?

In the past half decade or so, Git has sky rocketed in popularity and is becoming the defacto choice for version control. While I understand its popularity, I have found it to be a poor fit for one specific, but popular, environment: SaaS development in a medium to large size enterprise.

Let’s take a quick look at what developing software in a SaaS enterprise is like. For the most part, it involves a significant number of developers concurrently committing code to a single master branch with frequent releases to prod and no long lived branches or versions. In a services environment, it also includes coordinated deployment of multiple services that have complementary server and client API spec.

While Git has been used in such environments with varying degrees of success, I have seen teams really trying to work around Git rather than Git just work for them. I have seen Git get in the way when teams get large, when teams get siloed into their own branches, when teams starts working with junior developers, and when having to develop across multiple services. While there are mechanisms in Git workflows and tools to mitigate this, it only adds additional complexity to developing software instead of taking it away.

Continue reading “Git may not be the best for SaaS companies” →

When should you build for survival?

source: http://beaconbusinessmarketing.com/success-vs-survival/

Previously, I wrote about building for survival vs. success. Briefly, when building for survival, your only goal to get the product working for the specific usecase, and in contrast, when building for success, you are building to solve a bigger class of problems within the broader context of your solution space. In this post, I will talk about when you should be build for survival, and when for success.

Continue reading “When should you build for survival?” →

Are you building for survival or Survival?

Source: https://www.youtube.com/attribution?v=oW2i6QpnmyY

In my experience, the approach to building a software artifact often falls into one of two types: building for survival, or building for success.

When building for survival, your only goal to get the product working for the specific usecase(s) that will save your skin. In contrast, when building for success, you are building to solve more than just the immediate problem; you are building to set up building blocks that is incidentally used to solve the immediate problem, but can also be adapted to solve a larger class of problems within the same context.

This post is not about when to choose what approach. Instead, it is about what each of the two approaches look like, and what purposes they serve. A subsequent post will talk about when I think each approach is appropriate.

Continue reading “Are you building for survival or Survival?” →

Object Composition for Service Migration

Object Composition is a very powerful and pervasive software design technique. Yet, paradoxically, it is an underutilized design pattern whose lack of usage is the root of many anti-patterns in software development. One that I continue to come across regularly has to do with not using composition to test and migrate a piece of software from one service to another.

Briefly, Object Composition is combining two or more objects to create more complex objects while keeping definitions of the constituent objects unchanged (unlike inheritance, which extends these definitions)

Continue reading “Object Composition for Service Migration” →