<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Tenet on Panji Gautama</title><link>https://panjigautama.com/categories/tenet/</link><description>Recent content in Tenet on Panji Gautama</description><generator>Hugo</generator><language>en</language><copyright>Copyright © Panji Gautama</copyright><lastBuildDate>Wed, 17 Nov 2021 09:56:06 +0000</lastBuildDate><atom:link href="https://panjigautama.com/categories/tenet/index.xml" rel="self" type="application/rss+xml"/><item><title>Defect/Bug Management</title><link>https://panjigautama.com/defect-bug-management/</link><pubDate>Wed, 17 Nov 2021 08:30:33 +0000</pubDate><guid>https://panjigautama.com/defect-bug-management/</guid><description>&lt;p&gt;&lt;img src="https://panjigautama.com/images/JadedPointlessBufeo-size_restricted.gif" alt=""&gt;&lt;/p&gt;
&lt;p&gt;who doesn&amp;rsquo;t love bugs? they are small yet beautiful&amp;hellip;ly ruining our life 🙂. Bug is inevitable, choosing 0 Bug as your OKR/KPI is an insane choice, it&amp;rsquo;s not impossible but it will astronomically hit your productivity &amp;amp; cost, your best bet is to manage it properly. So how are you organizing and managing these bugs? Assigning the right priority(by assessing its severity) is the key, inspired by a couple of references, here is how I typically categorize them.&lt;/p&gt;</description></item><item><title>Software Fragmentation - The Golden Path</title><link>https://panjigautama.com/software-fragmentation-the-golden-path/</link><pubDate>Wed, 25 Aug 2021 09:29:07 +0000</pubDate><guid>https://panjigautama.com/software-fragmentation-the-golden-path/</guid><description>&lt;p&gt;&lt;img src="https://panjigautama.com/images/32f8ee1f68495231452451a2edfe9b7b.gif" alt=""&gt;&lt;/p&gt;
&lt;p&gt;There is a direct correlation between teams that give their engineers autonomy to own their technical decisions and the team&amp;rsquo;s ability to hire and retain A-class or Senior talent. There is a tradeoff, but an acceptable level of chaos in exchange for a stronger sense of individual/team ownership is usually the right one and leads to higher performing teams in the long run - at least this is what I&amp;rsquo;ve been seeing if a couple of companies in Indonesia.&lt;/p&gt;</description></item><item><title>Manager Manifesto</title><link>https://panjigautama.com/manager-manifesto/</link><pubDate>Fri, 16 Apr 2021 11:41:27 +0000</pubDate><guid>https://panjigautama.com/manager-manifesto/</guid><description>&lt;p&gt;&lt;img src="https://panjigautama.com/images/200w.gif" alt=""&gt;&lt;/p&gt;
&lt;h2 id="manifesto"&gt;Manifesto&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;Giving critical feedback or having difficult conversations&lt;/li&gt;
&lt;li&gt;Assessing whether a product is ready for launch&lt;/li&gt;
&lt;li&gt;Designing and executing a realistic roadmap&lt;/li&gt;
&lt;li&gt;Setting good goals with accountability&lt;/li&gt;
&lt;li&gt;Building viable new products&lt;/li&gt;
&lt;li&gt;Managing a team during “war time” versus “peace time”&lt;/li&gt;
&lt;li&gt;Defining quality&lt;/li&gt;
&lt;li&gt;Determining who to hire&lt;/li&gt;
&lt;li&gt;Understanding people’s skills, strengths, and growth trajectories&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="helping-people-reach-a-common-goal"&gt;&lt;strong&gt;Helping people reach a common goal&lt;/strong&gt;&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;Listening and learning about people’s aspirations and frustrations.&lt;/li&gt;
&lt;li&gt;Mentoring and advising, generally in the form of providing frameworks rather than here’s-what-you-should-be-doing’s (which is a whole topic for another time).&lt;/li&gt;
&lt;li&gt;Designing better and more efficient ways for people to communicate, work, or learn.&lt;/li&gt;
&lt;li&gt;Context-switching often in your day-to-day.&lt;/li&gt;
&lt;li&gt;Playing a key role in the flow of communication (writing, sharing, meeting, presenting).&lt;/li&gt;
&lt;li&gt;Owning the outcome of the team’s successes and failures, even if you won’t make all the decisions yourself.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;em&gt;note : not mine and nor I wanted to take credit on this points. I took this note awhile ago and unfortunately didn&amp;rsquo;t put the source link.&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Engineering Initiative, where to start?</title><link>https://panjigautama.com/engineering-initiative-where-to-start/</link><pubDate>Thu, 18 Mar 2021 11:31:04 +0000</pubDate><guid>https://panjigautama.com/engineering-initiative-where-to-start/</guid><description>&lt;p&gt;Performance improvement we must do, but where to identify it? Sometimes this kind of things might not obvious as they are, as experience and frame of reference from each of the individual engineer within your team might vary.&lt;/p&gt;
&lt;p&gt;This post intended to share questions and framework that I&amp;rsquo;ve been using (and pushing) to my team to give cue and where to start on finding room for engineering improvements.&lt;/p&gt;
&lt;p&gt;We start with very basic &lt;a href="http://www.barbaraminto.com/"&gt;Minto Pyramid&lt;/a&gt; framework to help us have clear written thoughts of problems &amp;amp; solutions.&lt;/p&gt;</description></item><item><title>Engineering North Star Metrics</title><link>https://panjigautama.com/engineering-north-star-metrics/</link><pubDate>Sat, 09 Jan 2021 12:11:10 +0000</pubDate><guid>https://panjigautama.com/engineering-north-star-metrics/</guid><description>&lt;p&gt;In the world where all of the metrics are available to be fetch and tracked, we end up on too many things being measured or worst, too little things that are being measured. It is impractical to make smart decisions based upon all available data and impossible to make any decision without data, and virtually impossible to make every metric as a priority worthy of improvement. The first challenge is deciding on what to measure, this article is intended to propose following metrics as the de jure metrics that being tracked and constantly improved going forward within tech team that I led so far.&lt;/p&gt;</description></item><item><title>Guidance on Creating New Service</title><link>https://panjigautama.com/76-2/</link><pubDate>Sun, 03 Jan 2021 17:07:11 +0000</pubDate><guid>https://panjigautama.com/76-2/</guid><description>&lt;p&gt;&lt;img src="https://panjigautama.com/images/b5894c49-87f0-4ac0-8954-2460cb92c4bf.png" alt=""&gt;something that we definitely don’t want to happen to us 🙂&lt;/p&gt;
&lt;p&gt;At any tech company, we work with a lot of legacy systems and monoliths. As engineers, our first instinct would be to decouple these monolithic applications into microservices architectures so we can have cleaner code and an easier system to maintain. While this is definitely a good goal to have, sometimes we focus too much on the technical side of things (architecture, scalability, implementations) and lose sight of the bigger picture. Hopefully, this document can be guidance on other aspects we should think about.&lt;/p&gt;</description></item></channel></rss>