Tagged: everyday company culture Toggle Comment Threads | Keyboard Shortcuts

  • kmitov 9:09 am on March 11, 2020 Permalink |
    Tags: awesome, , everyday company culture,   

    They will leave you, if they tell you everything is fine – [Everyday Company Culture] 

    Culture is how we do stuff around here. Read more about the [Everyday Company Culture] series.

    Today’s resolution. TL;DR

    If team members tell you everything is fine, it’s like a sure sign they will leave you.

    Today’s case

    People leave your organization for different reasons. One pattern I’ve noticed, learned and observed through the years is that people leave when “everything is fine” and people stay when there is a “list of things that are wrong”. People stay for “something” to fight for, because “something” is not right. People don’t stay because “everything is awesome”.

    As a manager be careful when team members return a positive feedback. Of course you want a positive feedback and you want people to be happy. But this does not mean there are no things to work towards to. Get feedback constantly, list things that are still not OK and work towards improving and resolving them.

    Root cause

    “Everything is fine” could mean that people don’t care enough to point the problems.

    Full story

    A team member of our organization left us yesterday. He was a great guy with great potential. As a software product company we are working on developing frameworks and solutions and this requires a great set of skills. It is certainly not a regular software development job. We are the ones building the platforms and the frameworks and providing them to clients and other developers. My experience is that not many people could grasp the concepts, importance and rules when building things like a sustainable API. This guy did, but he left us yesterday as he wanted to explore a different career path. (yek, this is more corporate sounding that I am comfortable with, but you get the point)

    Anyway, this finally prompt me to write this article and get deeper into. I hope members in and out of our organization could benefit by identifying and approaching such cases. Looking even at my personal experience as I have left two companies in my career, I did left when everything was kind of ok.

    Feedback and retrospective is a must

    We do regular retrospectives and I try to get more formalized feedback from team members. This happens once every 1-2 months with a simple Trello card where everybody should answer a few simple questions like:

    1. What are we doing wrong
    2. What are we doing right
    3. What could we improve

    Team members answer these questions publicly or privately to their managers.

    We are also doing regular 1-on-1 discussions (because we are not doing meetings…) and talk about how our organization is doing. The means of receiving feedback could be different, but it is important to give and receive feedback regularly. Even on a daily basis. Of course, you don’t have to solve every issue over lunch, but you could take a note (literally take a note and write it down) if in a conversation someone is mentioning that they have a “problem with something”. After all your job is to address this.

    On these regular retrospectives I try to be the first to return feedback and be honest of where we are, what have we done and what we could improve.

    67 things we could improve – co-founder

    On one of this discussions we sat down with my co-founder and we started sharing all the things that we don’t like. We wrote them down. Every one of them. One of them was of course “we should make more money”. But the others 66 were basically not connected with money at all and were rather small things in the whole organization. So we were happy that we have a basics right and in the large picture we are ok and moving in the right direction. But there were 66 things we came up with in about an hour that we thing we should improve.

    Example – one of them was “more A/B testing” before taking decisions. Since then we have done about 15 different tests that help us learned more and we are doing more structured A/B testing. Yet still, if currently we have to list the things that we could improve “more A/B testing” would make it to the list as there are still some decisions that we make based on a “feeling, preference and common sense”, which could be correct, but are not based on data.

    Point is – there are still things we could improve and we want to improve and we want to stay for.

    ‘I am a problem’ – VP of Engineering

    I’ve constantly received feedback from our VP of Engineering. He is sharing it publicly to the whole team and is somewhere on the lines of “I think that the organization is great, but It seems that I am not doing enough and I am trying to change this,…”. Here again – other things are great, of course we could always get more clients, but it is “me that is not doing enough and I am working on fixing this”. There are few things better than hearing your VP of Engineering, that has the largest engineering experience than any other in the organization, come to the office and say “Yesterday I learned how we could do this thing x2 times faster”

    ‘Our code needs to improve’

    As a software company we are working on our code. In one of our latest products we have one of the most clean code that I’ve ever seen. We could deliver in minutes. Modularity is great. Concerns are separated. Almost no redundancy and coupling. Automatic tests for different modules run in seconds. It is just really fun.

    Yet I’ve constantly received feedback that “our code needs to improve”. Because there is always room for improvement. This tests that are running for 15 seconds could now run for 5. This class could be renamed to make it more clear. This method could be called with different params and refactored. And the code could be made even more beautiful. We have a backlog of about 81 things that are exactly this. Not features, but just things to improve and make even better. So we prioritize and work on them in order. As we work we would learn more and the backlog grows even further and that’s ok.

    Point is, there are things that we are working towards to in the code. The code is never fine.

    “Everything is OK” and why at least ONE thing is not OK.

    Compare the above three examples with an “Everything is fine” feedback. No, it is not fine. It can never be fine. You could be doing too much meetings. Probably you are. Or sending to much emails. Probably you are. You could have unclear responsibilities. You could have people on positions that are not appropriate for them.

    Again, the point is that even if everything else in your organization is fine internally, even if you are the greatest “leader of all times”, even when people are earning enough, there is one thing that is still not fine. This thing is the reason your organization exist and the reason you’ve gathered your team. In our case – “people get confused and feel a lot of frustration when they don’t have an easy to follow 3D assembly instructions available instantly on their device”. This is the reason we are developing our products. After all, you’ve gathered together as a team to tackle a problem and even if everything else is “OK”, it is still not OK that there are people feeling pain and in need of your medicine.

     

  • kmitov 7:47 am on February 21, 2020 Permalink |
    Tags: , everyday company culture,   

    Feedback could come in any form, not just the one that makes it easy to accept it – [Everyday Company Culture] 

    Culture is how we do stuff around here. Read more about the [Everyday Company Culture] series.

    Today’s resolution. TL;DR

    Feedback from the team could be returned in any form, not only formally, not only verbally, not explicitly, but by the day to day mistakes that we make. Accept all kinds of feedback. Don’t be a “douchebag”.

    Today’s case

    There was a requirement for everybody to write the text “Result” as a first line in the comment of his/her work when marking a task as completed. People were following the rule, but writing “reuslt”, “results”, “Done:”, “Restult”, “Release:” and many others, but were not writing “Result”.

    Instead of pushing for everybody to use the right “Result” at the end we ended up with a list of possible “results” that team members could write as the first line of their result description. It turn out to be pretty funny to add new results and as of today this is the list of all the possible values, accepted by the platform. 

    possible_results = ["result", 
  "results", 
  "result:", "results:", #These are added because of Ivan
  "rrrrrr", 
  "rrR", 
  "blabla result", 
  "result blabla", 
  "Special Result Line", 
  "The Result:", 
  "Release:", 
  "Release", 
  "Take this result Kiril, I hope you are having a great time",
  "Resutl", # this one is added because of Mihail
  "Restult", # this one is added because of Mihail
  "Ready:", # this one is added because of Mitaka
  "Ready", # this one is added because of Mitaka
  "Done:", # this one is added because of Aleks
  "Done", # This one is added because of Aleks
  ]

    These results are accepted in any form of case – upper and lower. We have a team member that submits his results as:

    TaKe ThIs ReSuLt KiRiL, i HoPe YoU aRe HaViNg A gReAt TiMe

    Which is arguably, very funny.

    Root cause

    Feedback was not accepted. 

    We as a team all accepted that we should have “Result” of the work and we should have a description what is actually the result. Generally the result is different from the goals of the task. The goal is “develop a feature”. But the result is “visit this URL to see the feature”.

    We were just making mistakes when marking the result and I was pushing for the use of the correct word which is:”Result”. Nobody returned an explicit, verbal feedback – “I think we should make the result with ‘Done:’, because I don’t like writing ‘Result:'”. Nobody said this. We all understood that there should be a rule and we should follow the rule. But we were just making mistakes.

    Full Story

    I was trying to establish a rule in the team – when a piece of “work” is completed you must provide a short description, URL link, commit, picture/video of the new feature. This makes it extremely easy to generate release notes that we make public to the client. Only rule was

    “When you submit your the description of the result the text must start with ‘Result’“.

    Something like this will be enough

    Result

    We have implemented a new feature that shows a progress bar when downloading the assembly instruction.

    Here is how it looks like

    https://s3.amazonaws.com/fllcasts/content_pictures/pictures/000/003/479/4d609c2301bbe94f7a1c9825b7a2d85275c18537IS-Showing-Progress.png?1581586917

    After the result is provided we use different internal tools and I could easily generate public client Release Notes for our products and platforms. Examples at: https://www.axlessoft.com/release-notes or http://fllcasts.com/release-notes

    Sounds easy. Only thing you have to do is start your description with “Result”, because other values could be “time track:”, “Code Review”, etc. It took me weeks before I finally realize that we should not be strict on the value “Result”. We should be strict on the behavior that everybody should write a result, but if you happen to make a mistake and write “resTult” – that should not be a problem. We got you on the platform end, accepting different input values for result. Does not matter how you call it, as long as it is there.

     

  • kmitov 6:34 am on February 21, 2020 Permalink |
    Tags: , everyday company culture   

    Everyday Company Culture – what’s it about 

    Culture is how we do stuff around here. Every day there is a new challenge with communication, transparency, accountability, with what we value and what we think of the world (mainly inside of our organization).

    With the Everyday Company Culture series I am trying to look at specific cases, the root cause of the challenge and how we approach them. This approach is different form setting X high level, single word values that are understood differently by each member in organization. Example – transparency. It is easy to aim for a ‘transparency’ in an organization. It is difficult to properly communicate what is ‘transparency’. Same for ‘diversity’, ‘accountability’, ‘clarity in communication’, etc.

    My hope is that this series could bring more value inside of our organization and hopefully help other small and large teams work better.

    Check out the full series at http://kmitov.com/posts/category/everyday-company-culture/

     

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel