Category Archives: Workplace

Make yourself a valuable employee by measuring your Net Promoter Score

As a freelance I often face the request to report about my delivery, to assess the effect of my actions and suggestions. During my years spent as an employee though, I learned to ask my colleagues for an assesment with the aim to become more valuable to them. If we all agree business must be user-centred, then why not being user-centred when working as an employee too?

Feedback is paramount

I have been a developer and then an entrepreneur well fond of agile methods since 2004. Through the practices described in Extreme Programming I have learned that feedback is a value. All the agile body of knowledge is based on this: no matter where you want to go, to get there you need to know where you are. Without exception.

Net Promoter Score

A few years ago I started a pleasant working experience in eBay Classifieds, working with the regional italian team based in Milan. During those years I have learned a user research technique called Net Promoter Score (NPS), a surveying technique which I ended up appreciating a lot.

Basically the NPS is one single end-to-end strongly value-oriented question asked the customers about the service or the product you are selling to them:

How likely are you going to suggest [our product/service] to friends and relatives?

Katia, the product manager which was at that time on her way to move and join the canadian eBay Classifieds team in Toronto, left her handbook about NPS to me and I got the chance to deepen my understanding of the technique. I immediately loved it because it doesn’t start the analysis of the user experience through a pre-packaged mindset – embedded in a number of questions. It leaves instead the first feedback to be gathered by a single, all-comprehensive, all-round question which allows for structures, for the mindset of customers to emerge.

Performance appraisal

When I started working as an employee I expected to meet some yearly performance appraisal procedure and I was not wrong. Neither was I wrong about one thing I already thought: performance appraisal is flawed.

Assuming that it should be measured at all, individual performance always ends up being measured on a subjective basis. Everywhere I saw it measured, I regularly saw rational and objective criteria being spoiled by subjective and personal judgement. Let me be clear: I am not saying it was sistematically intentionally spoiled by evil managers. I am just saying that even the best intentions of the mildest person fail to deliver a good evaluation if they are just driven by an evaluation grid, no matter how sophisticated the grid.

  • A grid must be decided upfront, which is hard to do, especially with newcomers.
  • A grid hardly fits all the profiles a company has to cope with, no matter how fine is the grain of its parameters.
  • A grid defined upfront is not robust against reality checks: what if an employee starts delivering lots of value in a direction and in a way initially not expected?

These flaws, no matter the company, no matter the good intentions of managers involved, always lead back to a late guts-based reshaping of the performance appraisal parameters, goals and procedure. What was built to describe people’s performance with distance and democratic coolness becomes dominated by gossip, confirmation bias and backward looking metrics again. Fail.

Working around performance appraisal

Flash forward, left eBay but still working as an employee, during the spring 2014 I asked myself: “Do I want to know more about how my value is perceived by my colleagues?”. Yes. “May I consider myself a service provider within a company? Do I know any nice way to evaluate the value perceived by service or product users?” Yes and yes. If my performance appraisal must be necessarily biased, I thought, then why not to include and integrate those biases once and for all in a single end-to-end user-oriented question meant to catch all the nuances of my value delivery within the company? Sure the answers will still be subjective, tainted by prejudice and altered by fondness but at least they will be cheap to get, open to unknown serendipitous implications and continuously matching the shape of the real value delivery.

Asking THE question to your colleagues

All in all how much could I be sure of being of any real value to all the colleagues I was working with month by month? This is was the question, the only one worth asking for, and I decided to ask it every 30 days to all the people I had worked with.

First release

I created a Google Form with the very basic question:

How likely are you to recommend me as a person to work with?

and I started sending the link to the form every month to all the people who I had had the chance to work with during the previous month, no matter the role, no matter the task. The people contributing with their answers were asked no name, no further data, no further details. They could sharply assess my value contribution with a very short question, while protected by anonymity.

At first it was only the bare minimal question but very soon I added an optional second question only asked in case the main rating was below 7. This question was expressed more or less this way:

What could I do differently to bring your answer to 10?

My aim was to play a perfection game upon myself. Being focused on my “customers and users’” feedback, I decided to shape my improvement as an employee around the feedback coming from my colleagues. Later on I realized that giving them no chance to provide me with an open feedback in case of high rating was keeping an important set of information hidden from my eyes. I realized I needed to know what I was doing right as well as what I was doing wrong. So I made the second open question available to all the people who answered the first one, no matter the rating given. The second question became:

What’s the rationale for your rating?

[Here you find all the ratings and comments, except for confidential excerpts and data.]

What I learned

I have run this exercise for almost one year and I learned a lot, about my colleagues, about organizations and, you guessed it, about myself.

Continous improvement of value delivery

Every month I had the chance to question my own status quo, assessing in a very simple way whether I was truly helping people around me. Simple requests like:

more concreteness in the followup after being engaged in some activities

or like

Help me to receive the strategies of the company, decisions, and be more involved not only if I ask […]

were very helpful in shaping my work, month by month, day by day.

I came to love the end-to-end nature of the question. It encapsulates all the aspects of value delivery: was I using the right skill in the right place? Maybe. Was I skilled enough to be helpful? Maybe. Was I communicating achievements thoroughly and clearly? Maybe. Was I conceiving value itself in a way compatible with company’s values? Maybe. The assessment I was performing more or less every four weeks was taking care of the whole pipeline and this was returning a dramatic insight.

Walking the talk

I have developed software for years, for more than 2 decades. Since 2004 I have practiced agile software development and I have always faced the problem of bringing people with me along this path: friends, business partners, colleagues, audiences, not to mention coachees and customers. As always, trying to change people’s behaviour induces some amount of resistance and I learned that doing in first person what you ask to do is one of the key change enabler. Thus I have always asked people to start writing automated tests, but I wrote them first. I proposed to practice Test Driven Development, but I have always coded this way on my own. I started questioning the way we write contracts and in the face of skepticism I experimented with my own company first.

So it felt perfectly natural to me now to start asking for a different feedback about myself as an employee, to directly challenge the status quo of performance appraisal. Once privately deployed this kind of informal, anonymous and comprehensive assessment about myself, no one anymore could argue it was a request made with no skin in the game. Performance appraisal could suddenly be discussed on a wider level with no protections from ivory towers.

Improved peer-to-peer reputation

When I started and continued to ask for my NPS, people saw I was exposing myself to their own judgement. I had everything to lose. My reputation could be vandalised by anonymous colleagues on the mere basis of aversion but this simply didn’t happen. All the colleagues participating month by month provided me with honest feedback, not always positive, but never violent and never unnecessary.

It is amazing how raising the stakes about yourself and showing that you are playing with your skin in the game makes everyone more respectful and explicitely aware of your presence in the same company. That made me feel good for sure, relying on a network of ongoing real human relationships, instead of being just a set of numbers in a goal grid. Even my boss, who would have later expressed doubts about the value of our collaboration, had to score this as a point on my side. This leads to my next point.

Stronger position in negotiations

When the first six months had passed, I could rely on the first bunch of collected feedbacks to extract some information about my trend. Was I improving? Was I not? Along with my personal NPS data, the company was going on evaluating my performance as usual and everything was under control, with a clear demand of value and a “good” performance – according to their metrics.

After other six months things had changed. The layout of the organizations had changed and my role became less defined, spread on too many fronts and my value less evident to my boss and his boss. It was not clear what the demand from the higher levels of the hierarchy was and I started to feel uncomfortable with the situation. I eventually decided to negotiate an exit from the company.

Still though, my NPS kept on rocking, stating loud and clear that people working with me side by side, no matter the formal hierarchy, they were all acknowledging the benefit of working together. Sometimes they were expressing some legitimate critics, but not absolutely denying I was a valuable colleague. Indeed, those real time critics were validating my whole NPS thing.

That result, more than the official appraisal metrics – according to which, by the way, I was still a good performer – was the key for negotiating a good exit from the company. Once again collecting data, even just gathering opinions in some structured and continued way, proved its amazing effectiveness for providing arguments in tricky times.

What I’d do differently now

I have asked myself what I’d do differently if I was to repeat this experience, or better, when I will repeat this experience. This is what I thought:

  • Maybe I’d let the chance to sign the feedback. Sometimes I would have loved to ask to someone for deeper insight, for a more articulated opinion, to make me better understand their point of view. I don’t know what I would exactly lose with this. Maybe people would feel forced to provide their name anyway, in spite of the optional choice, and this would cause a drop in participation. Maybe people would be afraid to be the only one not signing, eventually exposing them anyway. I don’t know and I wouldn’t without trying for real. If I will ever do it I will let you know 🙂
  • I would publish the collected answers month by month, in order to raise the awareness of this operation as a whole team. I think it would have induced more people to join me and would also have reinforced the open culture I was instead fostering alone this way.
  • Public or not, I would allow my boss to read my NPS data, maybe even upper managers. I think it would have provided them with some real time idea on how to fine-tune their demand instead of waiting for an entire six months before starting discussing my delivery. When official appraisal arrived, it was too late. Having had my colleagues’ feedback in their hands would not have necessarily meant they agreed, but at least it would have triggered the meaningful conversation that were needed to fix the collaboration before it was too late.

In the end

Please beware: I am not saying that NPS is enough to prove the absolute quality of your work. I am just saying that it is cheaper and better shaped than any other mainstream performance appraisal technique I met. It triggers good conversations because it focuses on the way you contribute to the team action with least assumptions upfront. When proper conversations are in place, the need for assessing performance vanishes away. If you really can’t stay away from performance review, ifyou really have to perform regular appraisal, this is my proposal for a better way.

What I would not do any differently? Gathering feedback. A lot. Always.

Whenever I talk about feedback systems with a new team, usually someone exposes her concern about two aspects:

  • Won’t the feedback gathered be too much and overwhelming us?
  • Won’t gathering feedback be too costly?

Both concerns deserve the same answer: if you try and learn from your experiment, you also learn how to keep the feedback data cheap to collect and meaningful to read. If feedback is cheap, then it will never be too much.

How are you going to improve the feedback about yourself starting from tomorrow morning?

Dream of your build & build your dreams

Tonight I dreamt of Giorgio and Danilo. They were ticking me off. They were upset. The build was broken and they had just found a bug, introduced months before by me while refactoring some remote legacy area of our codebase. They were speaking words of reproach about how hard it would be to fix the bug now, being that code as legacy as untested code can be. They were blaming on me because I had introduced a bug in a hard-to-manipulate area of the code. How hard would the fix be now? Why, should I have ever refactor that untested code at all?

Just a few moments before waking up – or so it seemed – that apparent nightmare turned back into a dream: I had just committed very few lines of code at once throughout my refactoring thus it was very easy to backtrack my code change, get a very clear view of it and revert it. I got the solution, we learned a bit about our legacy code, thought I still kept my reproach.

Flashback to a few years ago.

I was refactoring a huge legacy codebase. The company I was working for had very very very very high maintenance costs due to the age of their codebase and the proud absence of automated tests. I wrote ‘proud’ because everyone was aware of the mere existence of automated testing technology but no one was even trying to introduce the benefits of automated testing in their daily life: “eh”, they kept on saying, “someone should do it sooner or later”.

I decided to do it.

Backlash

The problem with nasty legacy code is that often you have to refactor it before you may even consider introducing automated tests. That requires developers to be very careful performing very small step-by-step refactoring to work their way to the first automated tests. In that case it was even worse. (Legacy) security measures used to prevent bots to hijack the (legacy) web interface was making my job harder than hard: it was impossible to put some end-to-end testing in place, my usual first step to secure a legacy codebase.

I was not wise enough and I “broke the build”, though actually there was no automated build to break yet! The editing step was too big to be easily reverted and I disrupted the whole team activity. For 2 or 3 days the team has been complaining about my “refactoring fixation” and – as per standard policy – I was punished: I had to bring croissants for everybody the day after and I got a refactoring embargo, forbidding me any further refactoring for months.

Compare my past experience and my dream of today. What changed? What has still to change? I think I learned two main lessons, at least.

Continuous integration as an individual policy

Continuous integration is a personal policy first, then a team one, last an automated one. Keep it small, baby steps, allow for some observation time after pushing some virtually dangerous code into production. Nasty side effects could arise and you want to understand their root cause in a few seconds. Small meaningful commits are paramount and I really mean them:

  • Small so that is easy to scope them into your brain.
  • Meaningful so that their abstract consistency is kept high. It makes no sense committing half of a bug fix together with half of a refactoring.

Limit your work in progress, reduce the scope of your action. You don’t pay a per-commit fee so commit profusely! Also, being able to split your big problem into smaller ones is very good clue of your understanding of the problem.

A few years ago I was daring too much at once and playing with a way too big refactoring all at once. In the commit of my dreams (literally :-)) nowadays I just edit a few very consistent lines of code.

Don’t punish your volunteers.

I was in a team. The team was working in a very ill environment. I dared to try fixing our daily life. I succeeded in many places. I was wrong once. I got to pay a €20-equivalent fee in croissants and I was required to accept the status quo.

How. The hell. Does it. Make sense? No sense.

Well, I mean, I don’t expect everyone to be happy and congratulate with me for breaking production code. Neither I think that human actions should be judged only by their intentions: I may have the best ones, but a damage is a damage. Just don’t ask me to accept a rotten status quo just because that’s the only way to go, just because you don’t care enough to fix it.

All in all, you know, only those who do something are those that make mistakes. If you punish people for being wrong while trying to improve, you’ll only make them less willing to improve.

So what?

You may ask: “They shouldn’t have blamed on you. They shouldn’t have tolerated errors too. What do you think they should do then?”.

I think an healthy team builds a fault-tolerant environment up together to nurture an experiment-oriented atmosphere. I expect my teammates to build upon each other’s mistakes, analysing their root-cause and setting a new standard every day. A few years ago I expected my team to join me in the refactoring. In last night’s dream I expected my teammates to understand that introducing a bug while refactoring untestable code is as likely as in hearth surgery is to have a patient in atrial fibrillation: it’s bad but may always be a part of the game.

And fortunately you don’t even need to dream about Giorgio and Danilo to agree, do you? 🙂

Virtual & physical: the best of two worlds for our kanban board

Physical kanban boards are paramount to visualize the workflow of any company and engage people in managing it. Digital tools allow for remote work and for data crunching. A few months ago I asked myself: can we get the best of these two worlds?

It is now a few months that I joined Onebip, a mobile payment company. My main occupation here is to streamline the organisation to maximise its value stream, making sure we attack each bottleneck. Sometimes it comes to polishing the system deployment procedures, sometimes it is about making benefits and risks more visible to company’s strategists and sometimes it is about shaping the right (mix of) tools to serve the whole team needs.

People let uncomfortable tools down

When I arrived in Onebip everyone was nostalgic about the old kanban board. No one was truly using it anymore for a few important reasons: a part of the team is remotely located across Italy and Europe and some key managers wanted visibility on some metrics. The old index-cards-based kanban board was very good and appreciated by the team, but it was lacking the chance to be used and seen by remote teammates. It also allowed for no chance of computing the required metrics according to the team’s availability of time to compute them. These requirements left unfulfilled, the kanban board had grown used by just a part of the team, left out of the central role a kanban board should play:

  • a central meeting point for conversations, where people only talk about what is truly happening
  • an information radiator, capable of intruding in the peripheral view of people when bad patterns arise
  • a very usable tool which is a pleasure to use for everyone involved in those conversations

Digital is good and bad

I have already had my experiences with digital tools. They may be powerful but are dangerous too:

  • usually they propose you their way, instead of letting the team grow and forge its own tools
  • they don’t provide any muscular memory, giving people a very cheap way to just click and then let go
  • they are buried behind a browser window as long as you don’t click a few clicks to unveil their content

All in all they just miss a key point: they don’t become the totem of the community of people also known as ‘the company’.

One board to rule them all

We needed something to bring tasks front-center in our conversations, to engage people physically, to make flow visible to friends in Belgrade, Rome or Istanbul. I proposed to use:

  • Kanbanize, easy to customise, letting users veeeeery free to shape the board’s layout
  • an Epson EB-475Wi anamorphic interactive video projector which allows for people to gather around the screen projecting no annoying shadow
  • an HD Logitech webcam to reproduce telepresence

I had to put some extra care about Kanbanize CSS layout because the standard one was overloaded of commands that don’t favour a totemical conversations. I went for Stylebot, to just hide any exceeding DOM element and fine tune font size.

That’s it. As you may see in the video, now the whole company has its own powerful augmented real totem to drive its conversation.

If you are curious about other details or just to share your thoughts, feel free to comment here below or tweet me your comments through @jacoporomei. Ciao!