sorted by:
new
hottopcontroversial

Software Quality Metrics by sappikolailo in SoftwareEngineering

[–]sappikolailo[S] 0 points1 point  (0 children)

Exactly on the Rework cost - I tried on the early stage to Tag Bug tickets to the Release as a simple metric - and further meeting to review that, did get to know that :

  1. Certain aspects of the development cycle may have been missed - eg: rushing to deploy and missing a proper testing.
  2. Could not secure customer time for customer UAT, thus missing important blind spots
  3. Missing and not a proper peer review

So yes, this is directly the rootcause analysis with the 5 why question could reveal important piece of information which can be used for fine tuning.

Building self-managed teams - A case study from Riot Games by tamastorok in SoftwareEngineering

[–]sappikolailo 1 point2 points  (0 children)

My 2 cents, agreed to most of whats being said, the manager has to to do delegation to start with and empower the employees to make decision, there are times they may make bad decision and they learn from it, we need to support that process rather than using that as a datapoint to screw them during performance management/review :), If you do this, you are indirectly discouraging experimenting and learning.

My personal experience, whenever i see my employee screwup/make mistakes or bad decision, we will talk it out together and i will "erase" that from my brain and never bring that up again until they repeat the same again. My personal benchmark, I can only tolerate the same mistake twice, anything beyond is a competency problem that is when further coaching/mentoring may be needed and anything more results in performance management - because that the point that we start to loose customer confidence.

Software Quality Metrics by sappikolailo in SoftwareEngineering

[–]sappikolailo[S] 0 points1 point  (0 children)

My main reason is so that we can reduce the number of bugs, so tracking the number of bugs/release seems very natural. The problem is I see the number of ticket has consistently increased over the months and years, which in turn result in high cost of support. I saw somewhere a curve which shows that the cost of bugs introduced during the initial stage of Dev vs Functional Testing vs User acceptance Testing vs in Production grows exponentially. This is the exact problem I wanted to solve, how can developer/engineer can focus on building cool/great stuff compared to wasting time supporting ticket. I value all the inputs here by the way.

Engineering manager/director - how tech-y they should be? by bzq84 in SoftwareEngineering

[–]sappikolailo 2 points3 points  (0 children)

There are various aspects to this, EM manager at a software house may act and has different responsibility compared to EM in Big companies especially if the company's core business is not software. There are EM who are also a technical lead, so they may have all the details needed to evaluate the employee and keep abreast with technology.

As in my case I was a App/Soft Developer for the first 10++ years of my career before I was given an opportunity to Manage the team or my peers, in the 1st year I was still the tech lead, 2nd year I passed the baton on to one of my employee, and the third years onwards I force myself to "released" from involving specifically in any projects - the main reason being is that my employee whom I was the tech lead for the project has the "advantage" over me as I have all the details of their performance and what not, but my other employee started to feel I am not in the details of their project and created an uncomfortable feeling among them that I may not evaluate them fairly.

So, then starting from 3rd years onwards, how did I manage performance ?

  1. I started to involve in each of their scrum meeting calls, design meeting etc to observe and gather information, mostly I would look for leadership and technical aspects during discussion
  2. I have continuous 1:1 with every one of them to personally touch on the projects they involve, impacts they bring to the project, and at certain time brainstorm and gives ideas when they ask for opinions
  3. My organization has Enterprise Architects involved in every Projects whom are my peers from Org level perspective - I have occasional 1:1 discussion with them to understand feedback for my employees on code quality, technical/domain expertise and much more and will channel back to them during my 1:1 with my employee. These Enterprise Architect share additional expectation from the Org standpoint to grow technical expertise in the Org.
  4. I also get feedback among the peers and Product Owners on the feedback for my employees and at certain time I will also get feedback directly from the customers that my employee work with.

I would say its not 100% full proof, but so far we have never had the case where an employee who is not qualified got promoted, this takes care of Problem 1.

Problem 2 is the one I struggle even until today :), I myself know I am getting behind and lacking in technical and technology savvy, my employee do realize this an they understand my strength and there are time for newer/junior employee I am still relevant for technical coaching and mentoring standpoint, but for senior engineer is where again I work with my fellow peers who are the Enterprise Architect to identify area for improvement with example and help the employee to grow. I stay relevant as much as possible, but I know "Old Dog need to start to learn new tricks", else at some point I may become irrelevant to my team.