I am as surprised as you are at the title. The statement does seem like “Duh!”, but much to my embarrassment, I have seen enough code in many code bases to need to reiterate this.
The latest example was the following bug that I spotted. First some background. The caller to this function can choose any subset of a given set of ‘modes’ or ‘features’. The caller represents this via a bit-mask. So 1 represents feature 1, 2 represents feature 2, 4 represents feature 3, 8 represents feature 4, and so on. So, if the caller requests with bit-mask 3, then it represents features 1 and 2, and bit-mask 10 represents features 2 and 4.
The following piece of code is support to filter out requests depending on the requested set of ‘modes/’features’.
if ((bitMask & ModeEnum.FEATURE_FOO.getValue()) == 0) {
// FEATURE_FOO has already taken care off the by some other module. So do nothing here.
return null;
}
/* Some more code here */
if ((bitMask & ModeEnum.FEATURE_BAR.getValue()) == 0) {
// For now, we process the request only if caller explicitly specified FEATURE_BAR.
return null;
}
/* more code to process the request with FEATURE_BAR. */
The code above has a bug because the comment inside the first if-check does not match the if-check’s logic. The intent was to skip processing the request if FEATURE_FOO is enabled. Instead, it does the exact opposite.
The naive way to fix it would be to replace
if ((bitMask & ModeEnum.FEATURE_FOO.getValue()) == 0) {
with
if ((bitMask & ModeEnum.FEATURE_FOO.getValue()) != 0) {
However, this misses the more important point of why this bug occurred in the first place. The simple answer to that question is that this bug occurred because the author ignored the principle of code reuse. By putting that principle into practice, a cleaner way to write this code (and therefore fix this bug and prevent similar bugs in the future) is as follows.
We first encapsulate the logic to detecting various modes via this function
With that function in place, the new code looks as follows
if (!hasRequestedFeature(bitMask, ModeEnum.FEATURE_FOO)) {
// FEATURE_FOO has already taken care off the by some other module. So do nothing here.
return null;
}
/* Some more code here */
if (hasRequestedFeature(bitMask, ModeEnum.FEATURE_BAR)) {
// For now, we process the request only if caller explicitly specified FEATURE_BAR.
return null;
}
/* more code to process the request with FEATURE_BAR. */
This make the code more readable, and as long as we reuse the hasRequestedFeature() function, such bitwise operation fragility will not reoccur in the code.
Is this obvious? I think so. Was it necessary to belabor the point? Empirical evidence seems to scream “YES!”.
Saying goodbye to a workplace where you have spent a considerable amount of time is never easy. But it can be made into a positive experience by the organization, or be made miserable. Netflix is famous for celebrating when an employee leaves by thanking them and wishing them well, and in contrast, Hubspot is know for firing something and calling it a ‘graduation’.
I have two stories to share on how my departure from two different organizations played out. Both both these stories, there were only good intentions all around, but yet, the executions of the departure were very different. The juxtaposition is instructive on its own.
First story: I said goodbye, and they said Au Revoir
In the first story, I had a meeting with my manager and told him that I accepted an offer with another company, and so was leaving. His immediate response was to check with me if there was anything he could do that will make me change my mind (he also prefaced that by saying that he thinks that the answer is ‘no’). After I said that my mind was made up, he thanked me for everything I had done so far, and said that he will set up meetings with various folks to help me transition my responsibilities.
With my consent, he immediately and discretely told members of my team, set up transition discussions, and then followed that up with an org wide announcement. Then, the entire team got together for a goodbye lunch, with everyone including the manager wishing me well. Finally, before I left, he said that he wishes me the best, but if things don’t work out with the new role, then I am always welcome back.
Second Story: I said goodbye, and they said uh.. wait, what?
In the second story, I had a meeting with my manager and told him that I did not see my skills fitting the role, and that it doesn’t play to my strengths. So, I think serves both the org and me well to plan a transition for me to move on. He tried to convince me otherwise, and this went on for some time. I indulged his thoughts and arguments and made a good faith effort to pursue the avenues he suggested, but it only served to strengthen my initial proposition.
After I made my final decision, he asked to delay my decision until I had a new role. After I found a new role, he asked me to spend a month transitioning my responsibilities to someone else. But for over a week, I did not see any movement in the transition plan. Meanwhile, I am furiously preparing everything for the transition. Until about a week before my last day, there is no news of my departure, and no person or people to transition to.
With just over a week left, on my request, my manager calls the team together to announce my departure, except that he had already mentioned this to each of them private well over a week ago, but didn’t really provide any guidelines to them or to me about who else had been looped in. So, no one spoke to me about it, or to each other, and kept acting like everything was business as usual. It had become an elephant in the room and made everything uncomfortable for no apparent benefit.
Finally, the last few days were a frantic meeting spree with my transition of responsibilities to other folks, and my brain dump spread across multiple documents that was hastily reviewed by the team as my last day at work came and went.
My final goodbye was in an org-wide meeting where my manager thanked me for my contributions and wished me well.
Upward communication critical to organizational well-being and effectiveness. It is also notoriously difficult to get right due to the inherent power/authority differential involved in the hierarchy of any organization. Almost every place that I have seen upward communication done right focuses on mitigating this differential. Unfortunately, many organizations seem to be completely oblivious of how the existing power differential within a hierarchy can jeopardize upward communication.
Does your organization share this blind spot? For obvious reasons, it doesn’t help to ask the organization leaders about a blind spot. However, there are symptoms you can look for. Here are some examples, that I hope will help you see whether and why upward communication is failing in your organization. Note that all my experiences are from the software industry, and so I am focused only on software engineering organizations. So please keep that in mind as you read on.
Here are four IMHO important symptoms to look for.
Focusing on the format instead of a well thought out framework
Asymmetric commitment from the leadership on communciation
No reacting/responding to the contents of the communication
Not getting engineers’ buy-in
Format instead of framework
Any sort of ongoing upward communication tends to be only marginally useful if the organization does not have a framework within which the receive and process the communication. For instance, an organization may care about cross team collaboration, and could get information about this from employees through upward communication channels. However, without a framework for the employees to provide that feedback, the organization may not be able to glean much.
Unfortunately, organizations tend to conflate framework with format/template. When this happens you tend to see rigid templates or formats within which upward communication takes place leaving little space for nuance, reflection, and awareness to unforeseen issues. An example should make this clearer.
I worked in an organization which asked employees to fill out a weekly report. This report had mandatory questions such as “On a scale of 1 to 10, how happy were you working with other teams?” On the face of it, it might seem reasonable. But consider the following scenario.
An engineer who has had a bad week at work and wants to communicate that upward. She fills out her weekly report outlining her frustrations and why she hasn’t made as much progress and what’s blocking her. She proceeds to submit her feedback, but the tool rejects her submission because she didn’t answer the mandatory question. Effectively, the organization is saying “unless you give the information we seek, in the form that we prescribed, we are not interested in listening to you”.
When scenarios like these repeat themselves often enough, both the organization and the employees end up with blinders on what can and should be communicated. And that creates blind spots in the organization.
Asymmetriccommitment for communication
When an organization sets up expectations for upward communication, it is automatically asking its employees to invest time and effort into it. If the organization does make a corresponding commitment on its end, it becomes demotivating for the employees, and any upward communication becomes either perfunctory or severely biased.
I recall a case where senior leadership wanted regular progress updates from all teams, for slightly different audiences and use cases, the content was required to be slightly different. The ‘solution’ to this issue was that team leads fill out almost identical, but slightly different, contents in an online form, a doc, a presentation, and a spreadsheet so it is all available for senior leadership when they want to review it. This is a really good example of asymmetric commitment. The effort here is expected entirely from the employees, and little from the leadership.
In contrast, I worked in organizations where management and leadership worked on upward communication along multiple avenues depending on how the engineers worked, and how the engineers liked to communicate. There were weekly/monthly sync up meetings where the management and leadership took notes, which the engineers communicated in the manner that was most convenient for them (including just talking, or presentations, or code changes, or screenshots, or even demos). Apart from that, the managers were also always sitting with the teams they supported, paying attention to the chatter among engineers and engaging when they realized some important decision were being made. The mangers participated in the decision making by proving additional context as appropriate, noted the decision that the engineers took, and made it a point to follow up on its execution while making an effort to not be intrusive.
That is an example of the leadership and management demonstrating their commitment to upward communication.
Reaction to upward communication, or the lack thereof
One of the expectations following upward communication is that the leadership with react to the communication, and then follow through on their commitment to address the issues brought into focus. When this redressal and follow through is missing, the impact is palpable and the consequences can be detrimental.
A common example where I have seen this is when the teams are expected to report progress and roadblocks, but the roadblocks are ignored by the leadership with the assumption ‘the team will figure it out’. Or worse, at times, the leadership actually does not know what to do, but instead of making that a discussion, they choose to remain silent (for reasons that could constitute its own blog post). I assume I need not elaborate on the negative consequences of that behavior!
In cases where the leadership acts on upward communication, the impact can be dramatic and hugely positive. I recall two distinct cases in two different organizations I worked at, where the entire team had an unfavorable review of their manager. In response, the leadership immediately asked the managers to transition to a non-managerial role and re-org’d the teams so that they can have a different (and hopefully) more effective manager to support them.
Not getting engineers’ buy-in
Any upward communication process that does not get the engineers’ buy-in is bound to have limited success. Interestingly, this precipitates more communication processes that also do not have employee buy-in, and the cycle continues.
In one of the organizations I was at, the leadership, for reasons unknown, determined that a bespoke task tracking/project management tool be used. Very few engineers, if any, liked this tool. Yet, this was the tool of choice and decreed to be so. Not surprisingly, the tool was not well used, and so the leadership did not get the information they were looking for with respect to work done/progress made, etc. In response, the leadership created a new role that was focused on upward communication, and insisted that every team dedicate one person to perform this role. This not only took away one engineer from already resource-constrained teams, it also asked that engineer to execute a role that they weren’t really selected/skilled for. Naturally, that didn’t fare well either. There was improvement in upward communication as far as the leadership was concern, but it was not sufficient. So, the leadership decided that, harkening back to the Industrial Age, all teams should follow the exact same and synchronous development cadence and report progress on that exact cadence of the leadership. This cadence fit some teams better than others, and you can imagine the morale in the teams that ended with the short end of the stick there.
At no point during this entire affair did the leadership actually sit down with the engineers in various teams and actually ask them how the teams like to get work done, and how leadership could work with each team to accomplish the goals of the upward communication that was being sought.
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.
Listen
Empathize
Don’t take notes
Descend into the particular
Check with others
Socialize, if the issue is common
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.
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.
