Being Engineering Manager

no it’s not me

Like many other software engineers out there, I used to think that I’m not a “people” people (at least not a good one)

At last I found time to write about me as Engineering Manager, a very unique role which I still can’t comprehend what it really is. But hey that’s the beauty right! When we don’t know, trying to understand and then tinker that out.

It began a year and half ago, second semester of 2017. The first batch of so-called Engineering Manager at my company, what we did back then? Honestly I didn’t know! In the first month I still code, one big and important feature. At the same time I was the squad lead, scrum master, technical architect, coach, entertaining all stakeholder and -you know- doing that random management stuffs. It was real chaos, things needed to change.

Let Go, about being easy to yourself

Let go, may be that’s the keyword I learnt through out this journey. One by one I put all that roles to others, the equation is not how much we can help team but how many people we can empower and build the bridge together. By doing that I could have more time to find what that Engineering Manager really is. In first semester I did a lot of experimentation (I still do), what’s the proper way to approach a project, communication pattern with product and business team and how we do agile development.

There was time that I tried to bring all the team for scrum ceremony. As predicted the team is too large for single scrum ceremony, daily will last for 30 mins more.

On pressure, failures and all “that’s too much for me” moments

Unfortunately even when I let go many of that roles, my team was still too big -It was too big that we had to split this into 4 tribes throughout the year. There was time that burnt out is understatement to describe my physical and emotional being, and even worse when the outcome of that suffering was failure.

Did you ever hear that being a good leader, no matter what kind of leader you are, your mental state is your team mental state. When you’re sad, your team are. When you’re so optimistic, your team are. And when you’re frustrated, your team are! It was months of crunch time and I had too many timeout moment to counts, but that helped me. In every timeout I prayed, doing warrior breathing or throwing some random yoga pose. Then I would be ready to face my team with all the positivity needed.

I think it’s very important to have another interest outside our day job. At that time I happened to have yoga class every week, so it helped. Naturally yoga poses are very difficult, it needs focus, physical strength and high pain tolerant (coincident?), all of that helped me to empty my brain from all other things. So Refreshing.

Another thing I learnt on that period was comrades are important, people whom we go to battlefield together. I had a lot of discussion about architectural design, problem solving or even debate with them, it was up and down situation. But In that kind of situation your hearth would say that people will always be here to charge the storm together. Your comrades would understand what’s that smirk means, or will shed tears together on many emotional moments. -Yeah I shed many (happy) tears-

Oh man after you passed that, anything will look like a piece of cake for you

It’s people not users. it’s people not resource

No no, I will not talking about UI/UX, product research or anything. The adage means that when we say user we will detach the beingness of human from the word. It’s similar with when we say our team member as resource, they are human being not a resource like rocks or oils.

My second moment of chaos was on how I underestimate people’s disappointment, I was too naïve back then. The way I brought news to people is almost the same to every person, how I motivate them was with the same treatment. That was big mistake, even Harper Lee wrote about this more than 50 years ago “all men are not created equal”.

Like many other software engineers out there, I used to think that I’m not a “people” people (at least not a good one). No it’s not, from many feedbacks actually I’m quite good people people -apparently that’s just an unnecessary mental block-. After this realization, all possibility comes to my mind. I eagerly add my time to hear, trust and coach people in my team. Yes it is not perfect, but I’m trying.

Helicopter is not destined to be exploded

My last semester as Engineering Manager was easier, I had more time to think more broadly – some might say big picture or Helicopter view. On this mode many problems become more clear to me, very exciting right! I had several big contributions to my employer on this time period, when I have more time to think and identify what no one have time to think. This is also the uniqueness of this role, that I also have authority to drive and empower people to solve and respond to problem. But man it was not for granted.

These moments shaped my definition of Engineering Manager even further they defined me as human being. In this era I believe the most important is not exact definition and understanding but the ability to identify, respond and adapt quickly. At the end of the day if you ask me what’s Engineering Manager I would not be able to give that kind of definition you found on wikipedia. Instead I can tell stories and then let’s distill together what’s this.

It’s quite long story already and don’t forget to take it with a grain of salt. There are 34 `I` in this story, it can be just narcissistic article, but you made it to the end.

Good luck

How twisted life is

I found this day my daily intake of tea is replaced by warm honey and lemon, it’s not like I get lemon in my life then make lemonade out of it. This night is not different, in this dimmed lit room accompanied by warm liquid of honey and lemon I start my contemplation. You may call it the end of year contemplation, but it’s just me romanticising everything (just like always).

It started a couple of minutes ago, woke up in the middle of the night realising that I slept before taking Isya pray. Had planned to get quick shower but end up with an hour empty gazing into tub full of water, thinking how generous god to me lately or to be exact in my entire life.

Born into lovely family who support me, giving good break, reminding and keeping me as a normal human doing human thing. Well loves are loves, they come from everywhere and everything, and family always come first. All of loves I have was started from this little family of four, even though I never particularly close to my mother or father or my sister but I love them. It will sound cheesy, well I know they are there and being my home to me, a place I call “pulang”.

But I realise that life is not only about your first loves, it’s also first hates, first love outside your family and the loves you feel right this second. And all of that are always being the force pushing me through my days, being lemon at not so good day and being honey at the sweet day.

It all come slowly right? Your peaceful day to day you take for granted into full realisation of how twisted life is. I thought 9 years ago I understand it, 5 years later I thought how naive I was that day and now I think I understand how twisted life is. You can be so happy, so angry, so lonely, so graceful, so regretful, feeling being loved then feeling so lonely in other day, and name other thing you can imagine. I even felt sadness in the middle of my happiness, fearing the happiness will come to end. Like when you watch very beautiful movie and realising that the film will end eventually.

Started 4 years ago I like to fill my room with therapeutic aroma, this day I like to use two drops of Kamboja Essence with full bowl of Cajuput Oil. This night the scent feels so warm, the honey starting to kick in and the music just smoothing the feeling, now I’m ready to take another year ahead.

Then let’s see what it will bring, will my understanding of life remain the same, who knows.

Deadline Driven Development

DDD or Deadline Driven Development, a term popularized in a well written article by Joshua Partogi (1) is real yet interesting problem to solve. It is not easy to tackle but nothing impossible right?
For me as software developer having enough experience of DDD is understatement, I’m fed up with it. No MVP, impossible deadline, no clear long term product and bussines vision, Long crunch time and everything in between. Don’t blame developers who think they’re a victim of vicious process.
Fortunately that article comes with good solution by prioritizing, slicing by the amount of cost of delay then doing continuous improvement afterwards. I will not try to explain that points, but I will add my own here.

The main point is to stop thinking as a bunch of victims and realize that we are also part of that vicious cycle. Get the position and speak up, present your concerns and ideas with clear reasoning and back it with good data. It is our job to be a good break for them, and giving options for each concerns.
Crying about how bussines or products people never understand engineer is useless, they will never fully understand us. Always improve team’s confidence for the next wave of impossibility in terms of technical efficiency and ability.

I said that full mutual understanding is not possible but at the end of the day we must agree that our goal is the same.

(1) https://medium.com/modern-management/deadline-driven-development-metodologi-software-development-terpopular-di-indonesia-1ea67ab0cfd0

Alerting is an Art

Too much will make us overwhelmed which eventually lower our alertness to alerts that are important.

Too little makes us do not aware of the state of our system and may miss a problem.

Determining key metrics is the most important step to good alerting, then formulate any form of alert for those metrics. Then divide it into four important quadrants, make sure exposure for critical alert are greater than others or not buried by alerts that are in lower quadrants.

After all that division, now we can determine who should get each alert.

Oh and making sure alert recipient to understand key metric and urgency of each alert is also important.

Talking about Qt vs HTML5 whitepaper

It was in the middle of midnight when I stumbled upon a white-paper comparing Qt QML app development with web app development. I like the idea to compare these two wonderful technology, however more I read the white-paper more I dislike it. I think it’s just another misleading marketing stun. Let’s dive down a bit on this white-paper titled Qt QML vs HTML5 – A Practical Comparison.

So in this whitepaper an Austrian company tasked a developer to build an Embedded Application using QT and HTML5, the developer had 160 Hours to build the QT version then another 160 Hours for the HTML5 version. The developer was experienced in HTML5 and C++ but had little experience on building QT/QML apps.

From this point please read the whitepaper before continuing this post, for complete context.

The result

I think there is one main misconception which leads to inappropriate comparison in this whitepaper.

The definition of Embedded Application; I would say embedded application would come in packaged and controlled target machine, like for webapp we can pick whichever browser our app work best. And for QT apps would mean which operating system and hardware platform the apps is targeted, so we can limit the build number to release. On both software stack or in embedded application generally, limiting target environment means less testing and less extra variable to take into account.

Continue reading