Changing KPIs — A tale of moving from individual contributor to team lead.

Changing KPIs — Moving from individual contributor to team lead.

The biggest change after my move to team lead is that my KPIs (key performance indicators) have changed significantly. I still troubleshoot bugs, create architecture, discuss and persuade teammates of architectures. I get to write some code here and there. But the work that I am evaluated on has changed significantly. Instead of being evaluated on my ability to get coding done, to resolve bugs and be a good team member, I am evaluated based on the team’s performance. Was I able to keep everyone on the team from being blocked this sprint? Was I able to keep people on the team coordinated such that they didn’t duplicate code or write incompatible interfaces? Do we have the architecture and stories hashed out far ahead enough to keep working towards the release?

Its been kind of a shock to me because I will be giving my update in standup, trying to remember what I did yesterday and its something along the lines of “I sat in on a couple meetings, reviewed PRs and helped classify several bugs.” I worked all day and am exhausted now, but I didn’t commit any code or make any progress on the story I assigned to myself. It feels like I’m not getting anything done, what happened, I used to be good at my job.

But despite feeling like nothing is getting done, I am still hitting my KPIs as a team lead. My bosses are happy, the team seems happy enough with my work, the scrum master has what he needs, etc. Its not that I am not getting any work done, its that my ‘work’ has changed to something different. I am focused more on coordinating the team’s effort and planning what we need to do next, keeping abreast of the features coming down the roadmap, keeping track of technical debt and the maintenance work we need to do.

Starting a new Go project is delightful.

I started a couple projects recently, a mock crypto exchange and my latest project a unicode manipulation library. But what struck me is that its really simple to get started. You need the go runtime and a GOPATH setup.

Then you specify the package and the main method and that is a valid program.

package main

func main(){}

Above is my program so far. It is a short program with a bit of exploratory code that converts strings into their unicode rune ids. Back when I mainly used Java, I would have had to setup an IDE, integrated maven and think about package structure. In Go I just have a main.go file, if I need dependencies I create a /vendor directory and usego get github.com/gin-gonic/gin to pull the dependency.

Overall the lightweightness of the Go tooling makes it very easy to build small programs.

 

 

Code Challenge Usability Testing

Coding Challenges have become a common step in the Software engineering interview process. I have had to review a couple challenges and the biggest mistake is a lack of usability testing. People are usually in a rush when they do coding challenges, either to limit the amount of time they are spending, or because they decided to attempt something challenging and time is running out. When we do side projects we often think that because its just us less complications will come up and our estimates will be more accurate. But the reality is that the project is still going to take longer than you expected. 

Since most coding challenges end up being rushed, its surprisingly easy to stand out through usability testing. Ask a friend to clone your repository and try to get the code running without any support on your end. A surprising number of code samples and challenges don’t even start once they get into the interviewers hands. Or even worse, your code works perfectly, but the interviewers don’t realize it because you didn’t document what the ‘working’ state looked like well enough. 

It might seem like a simple thing to do, but just having two people try to start your app and give you feedback can result in a smooth stress free review of your code sample and give you a strong foot in the door.