Another week has gone and I am happy to continue to write here. My calendar-based organisation system is going well. At least, it’s better than I hoped. I am able to achieve closure on tasks and even gain some closure at the end of the day. Even if I don’t stick to my calendar schedule entirely, I still find I am able to balance my responsibilities and call it a day at the end of the day.
Most of my learnings this week have been reading related. It is still valuable to collect and document them.
Gutenberg problems
Technically, this falls under last week. But I am going to use it this week as I faced this problem when writing last week’s post. Gutenberg is the new editor for WordPress that supposedly gives the flexibility to create content with complex layouts. I lean towards structured content as a principle and don’t find this attractive. Still, I use WordPress for blogging (for now) and I was forced to use Gutenberg. It is not without problems though. More than once, whenever I undo a change, Gutenberg removes a significant portion of what I wrote, even blanking the post. Of course, I hit redo immediately but it does not give the whole thing back. For writing blog posts, this is really painful.
Last week when writing this post, I hit my limit and started looking for a solution. I found this plugin which disables Gutenberg and brings back the old editing layout. It’s weird to have to install that, but Gutenberg is more frustrating to deal with.
Pair Programming
Pair programming is cool. No, pair programming is required now. Even in a distributed organisation like Axelerant, pair programming is highly encouraged. Last week, I came across this podcast on Developing Up where they interview Ben Orenstein. He shared why it is a good idea to program together and how it helps in learning and making sure that the domain and product knowledge is spread through the team. He also explains how it might seem slow but it is actually more efficient in the long run. One of the tips I took away is to not use the word pair programming, but just asking someone to program with you and lend their eyes on your work. If you’re interested in detailed aspects of pair programming, do listen to the podcast.
Gitlab and Kubernetes
At work, I spent a significant portion of my week dealing with Gitlab CI issues on Kubernetes runners. I was configuring a pipeline with services and the service hostnames were not accessible. There was nothing in the documentation that would suggest it won’t work on Kubernetes and so I began hunting for a fix. I found from some open issues that the services are started but not accessible on different hostnames but on the localhost. If you’re using MySQL like me, you will find that localhost won’t work either as MySQL attempts to use sockets if it is localhost. That is easily fixed by using 127.0.0.1 instead. This is not a great workaround because it means that I can’t use two services on the same port. There is no proper fix to make it work like Docker executors either. There are a bunch of fixes in the queue which have been closed and continued in the next MR, and all of these involve just redirecting the hostname to localhost so that the service can use the same name as on Docker executor. These are the merge requests I found: 936, 1022, 1355, and 1680. As of right now, the last MR is open.
Make the hard choice
This article gives some well-founded advice on dealing with making decisions. While it may be appealing to completely rely on analytical processes to reach a decision, essentially making it black and white, this article talks about how the best decisions may not be possible this way. I possibly can’t do justice in summarizing it, so I will share a few phrases from there and add my own perspective.
The discussion starts with this story of someone who asked someone else to explain the Torah very quickly. He just responded with “That which is hateful unto you, do not do to your neighbor. That is the whole Torah. The rest is commentary. Go and study it.” He goes on with the more common phrase (which is a variant of the former in a way): “Do unto others as you would have them do unto you.” This is called the Golden Rule and the article goes on making a case why this should not be dismissed as moral sermonising.
I try to follow this myself both in my professional and personal life (they aren’t different, really). Paraphrasing something I heard recently and I try to take to my heart: “Help someone that they become like you, even better. Teach someone that they become even more learned than you.”
The cost of people (problems)
This HBR article is intriguing in how attempts to quantify qualitative problems are intriguing. I think it is a valuable indicator, but I am not putting too much stock in the numbers there. They are not surprising but I am not satisfied with how they were obtained. I should be using it as a guide to planning programs at work. The article then goes to talk about traps of trying to solve a problem from too close (essentially applying a brute force approach to the problem). They suggest solutions which are not radically different. They are about taking a step back and gaining additional perspectives, which is expected right now. It’s a useful read.
Resilience
I found another article (HBR again) which talks about resilience. It sounds very similar to delayed gratification studies. “Delayed Gratification” is a form of resilience, right? The article talks about three attributes to define resilience: Facing down reality, a staunch belief, and an ability to improvise situations.
The first attribute, facing down reality, is about being optimistic but also a realist. There is a story about Morgan Stanley, who were one of the biggest tenants at the World Trade Centre. The story is about how they were able to save most of their staff by being realistically prepared for anything. This story concludes with this phrase: “Multiple backup sites seemed like an incredible extravagance on September 10.”
I will just leave a few more phrases from the article. It is a worthwhile read.
Resilience is neither ethically good nor bad. It is merely the skill and the capacity to be robust under conditions of enormous stress and change.
“What we do not expect under life-threatening pressure is creativity.” In other words, the rules and regulations that make some companies appear less creative may actually make them more resilient in times of real turbulence.
Service teams
I found this post very apt to understand our organisation structure. It gives me more clarity and useful concepts to discuss and think about the service areas we have right now. There seems to be mixed word usage between capabilities and service teams but I think the underlying message is solid and aligned with what we are doing.
Productizing services
This HBR article is an elaborate write-up on how to productize services. Conceptually, there is little new here but the examples are helpful in understanding just what could be automated and hence productized. The text that struck me the most: “By contrast, low-volume tasks don’t provide enough data on which to base automation, while high-sophistication tasks are not easily automated because they require strategic decision making. For professional services companies, these opportunities simply aren’t worth the investment.”
For the kind of work we do, there are very few high volume tasks of low sophistication. The few we have, are solving it with building reference documentation rather than automating it. We could consider this next.
Structuring an organisation
I found a lot of takeaways in this article. Again, nothing radically different but presented in a very convincing way. There are five mistakes which make it very easy to identify problem areas in an organisation structure. Also, there is a discussion about roles and hats which gives me labels to think about the difference of owning tasks and being responsible for them. The whole article boils down to those five mistakes.
I am going to pull a phrase out of context: “So when creating the structure, ignore the people involved and just identify the core business functions that must be performed.” This comes up before in the article as well. When reorganizing, it is not easy to move people to new roles because of the baggage associated with titles and perceived power. The article gives an example at the end which shows how you can design a meaningful and reliable structure and indicates responsibilities (using PSIU) on a deceptively simple chart.
Flip the organisation chart
In this article, Joel Spolsky talks about flipping the organisation chart to indicate that the management is not a superior function, but a support function. “It means hiring smart people who get things done—and then getting the hell out of the way.”
This extends the idea of servant leadership and flips the organisation chart on its head. Another snippet from the article: “Thus, the upside-down pyramid. Stop thinking of the management team at the top of the organization. Start thinking of the software developers, the designers, the product managers, and the front line salespeople as the top of the organization.”
And another snippet: “The “management team” isn’t the “decision making” team. It’s a support function. You may want to call them administration instead of management, which will keep them from getting too big for their britches.”
Matrix organisations
In some of my earlier reading, I came across a term called Matrix organisation and from a brief readthrough, I thought our organisation was one. After reading this article, I am reconsidering if that’s the case.
More about organisational design
I found this in-depth article which covers design issues in an organisation and how it might be misdiagnosed. I think that we do see some of these problems at Axelerant. Particularly, I see the issue of excessive spans of control, especially in my own role. We also have to deal with bad role design but that problem is not that pronounced.
Leave a Reply