Posts Tagged People
Keeping knowledge workers loyal
Posted by Morten in Uncategorized on August 29, 2011
In a previous post I discussed how to keep knowledge workers motivated. There is a flipside to keeping them motivated because being motivated is only enough the keep the knowledge worker working well, but it might not prevent him or her from leaving. It’s not guaranteed that the employee is loyal.
To keep someone naturally loyal again we look at the Maslow hierarchy of needs. This time however we are going to assume that the employee is working on the self-actualization part of the hierarchy. If he or she isn’t then this might be a motivation problem and could be solved by finding out what’s wrong at the other level.
What would cause an employee to quit if even though that employee is self-actualizing within the company?
When an employee wants to quit its often due one or two things either its motivation based, things are bad at the workplace, want to work with something else etc. See my previous post. Or that employee has been offered “the dream job”. You might ask your self, why isn’t the current work place the “dream job”.
I think for a workplace to be the “dream job”. That workplace has to give something to the employee at each level of the Maslow hierarchy of needs. An employee is loyal to the company if he or she has parts of the needs for each level tied up within a company.
This is interesting because then we have to look at what does the company give to the employee? What’s in it for the employee?
An employee would be loyal if his or her Self-actualization is achieved to a large extent at the company. If the Esteem level comes from respect from colleagues and achievement at the workplace.
If the is a good social network of friends at the workplace. If the workplace feels safe. If the workplace gives security to the employees family through salary, vacation time and insurance.
If you consider how much investment or payoff an employee has at each level then you are considering how loyal that employee is. Helping an employee out in a rough spot causes loyalty, but also makes that person feel Safety at the workplace. It helps with belonging, and might help with Esteem.
My theory is then, that to keep knowledge workers loyal you have to constantly work to establish connections in the company to each level of the Maslow hierarchy and to the employees. This is hard and for most levels probably individual per employee work.
Keeping knowledge workers motivated
Posted by Morten in Uncategorized on August 22, 2011
I went through a rough spot recently, which caused me to look more closely at the![]()
Maslow’s hierarchy of needs theory. This post describes what I found out in a non-personal way because I think this can be highly useful for companies looking to keep their employees.
To summaries, Maslow figured out that in order to start self-actualization you would have to have some other needs met first. Once you achieve a certain level of needs to you start working on the second level striving up to Self-actualization.
To the right you’ll see an illustration of the Maslow hierarchy.
Notice that this is in fact an hierarchy. If someone whom had been working with Self-actualization suddenly lose a loved one, or finds him or her self in the middle of a war. It’s most likely that that person will jump down to work on Safety or Loving/belonging.
Being employed affects different parts of this hierarchy. The salary might give fill you Physiological needs for food, it might even help with feeling Safe since the salary helps you put a roof over your head. You might sense belonging at work due to your work friends. Your self-esteem is affected on how good you are at your work, if you get encouragement from colleagues. You can self-actualize if allowed to grow within the company, not based on rank or title but by being allowed to grow by learning, becoming better at what you love to do.
Now an employer should want one thing when hiring a someone: Does the employers self-actualization process align with the company? or in other words: Will the employee be motivated by working with this type of knowledge work? Hopefully all employee’s align in this way at the company at their respective roles.
If your hiring for a great developer, is development what this person will be fulfilled by doing? Will this person be self-actualized by developing new and interesting things and learn new things from his craft? Will that person self-actualize when working creatively to solve the customers problems?
The best performing knowledge workers work in the self-actualization of needs, and probably have done so for quite some time.
To keep such an employee in the self-actualization part of the hierarchy is good for the company, we need to realize that the other levels in the hierarchy needs to be fulfilled first.
If an employee looses a family member for some accident, then that employee will most likely start to mourn and work on the Love/belonging level of the hierarchy. So to keep an employee motivated, being informed about what’s happening to that employee and helping him or her get past that issue will get the employees motivation back on track faster.
If a employees house burns down, helping that employee find a temporary home for his or her family, will make sure the employee has his or her Physiological and Safety needs met.
If someone is bullied at work, making sure that person is respected and treated well at work will help that employee with Esteem and belonging needs.
In essence if you have a motivation problem with one of your employees, find out what’s wrong and see how you can help him or her to full fill the level of need he or she is working on right now. Once that person is back at self-actualization, most likely motivation is no longer a problem. Caring about your knowledge workers needs and cater to the to keep them at the Self-actualization level, will have them motivated and working creatively.
Or as someone said on Twitter: Tiered of coding? fix the other problem in your life and get on with it.
Continuous delivery implementations differ due to company testing culture
Posted by Morten in Uncategorized on July 25, 2011
I just finished reading a post about continuous delivery at Outbrain. It’s quite interesting they made a trip similar to what we have done at RemoteX. However their setup is some what different than in the our. They use a tool called Glu to do deploy to the their different target environments and deliver RPM’s for their services.
At RemoteX we produce .exe files as well as a set of web services so I guess there will be significant differences when looking at the actual deployment.
What I find interesting is that they seem to go directly from the builds in TeamCity to starting deployment, where we at RemoteX have several steps after the commit stage to package and verify our release before its pushed out.
Outbrain also seems to be able to target specific environments to deploy to in a greater extent than we do at RemoteX. At RemoteX we instead categories our system installations to gradually deploy to all our installations.
This brings up something that seems to be common when reading Continuous Delivery war stories. They all agree (mostly) what what Continuous Delivery is all about, but they all implement it differently and have different areas where the solution is stronger or weaker.
The pattern seems to be that once the product goes out to customers there are different cultures at the companies that requires different solutions. The example of deploying to specific environments or deploy to categories of customers for example.
These cultural differences seem to all be focused around faith in the quality of the product. With in turn boils down to faith and investment in automated testing vs. manual testing.
In theory it would be possible to see what the culture at a company is like regarding to their faith in their own deliverables, by looking at their continuous delivery solution.
Development as a team or development as stars?
Posted by Morten in Uncategorized on May 23, 2011
A good friend and colleague of mine Johan Andersson read somewhere that you can see the communication patterns of a company in the architecture. I can see how that makes sense, but I think its much clearer than that. I think you can see the communication patterns of a company in the interface of its products. Both API’s and UI.
Every bump in the flow of a product, every view that is different from the main theme, every glitch in the feel of the application. They all show where a Star has solved a problem. They all show where communication failed and brute force problem solving stepped in to save the day.
An example could be an integration that uses a mostly unused field to store some information that it was not meant to store. Such as dates being printed in a text-field. Or having to leave the application to complete parts of the workflow on a webpage (or on a different site).
If we consider an application and its features as an onion. At the heart of every application there is a core functionality, the minimum viable product. On this other features evolve, or are developed. In essence making it a bigger onion for every aspect covered.
It could look something like this:
| Teamwork feature circle | Star work feature circle |
Now let each layer be complete, if the workflow of the feature is complete. A layer is incomplete i.e. graphed, if they break the flow of the product in order to solve a problem. If they just add enough functionality so it solves the task at hand.
Naturally these describe the wholeness of the experience, and is not tied to the implementation in any other way other than the feeling one gets when using the product. A product developed with good teamwork feels whole and complete around each feature. A product developed with individual stars will still solve the task at hand, but the experience of using it is scattered and lacks flow.
Is this bad?
Pros
- The problem was solved
- Functionality is implemented as the customers wish
- A sale was hopefully made, money was gained
- It might have gone faster due to reduced communication costs
Cons
- There is a glitch in the workflow of the application
- Something looks astray if you consider the whole
- There is a severe risk of bugs being introduced at a later stage, due to things not working as expected
- It might cause rework to repair the flow, or fix the later introduced errors
These lists are probably longer, but they show the pattern
Let’s look at this from a sales perspective. If your method of selling is by listing features and selling a complete system, the stars approach is desirable, it will give you a list of features quickly. At the risk of the development going slower further down the road, especially if you build on “previous” features.
If you, however, sell by demos or free trials, showing the experience of the product and how convenient it is while solving the problem. Working with previous customers who testify to the product’s stability and trustworthiness. The teamwork approach will most likely give you the best experience, and reduced amount of bugs. Thus it might go faster in the long run.
From a buyers perspective, I’d rather use a product with complete flows.
Now ask yourself, are you a star or are you a team member?
How does your organization sell its products? Does selling like that benefit Star development or Team development?
What benefits your organization most? Teamwork or stars?
A pull process
Posted by Morten in Uncategorized on November 22, 2010
While reading The Power Of Pull, I came to think about push and pull processes. Now the definition of these is not the same as a push or pull process as used in that of lean processes, instead here a pull process regards an open platform on which participants can pull information from and add information too.
In essence an open-source project is often a pull platform, where people can access value from, attract more people willing to add value and achieve new value through the combination of new ideas.
So as I was reading I began thinking of how to build a pull platform for a company. Most companies are push processes, where a tight group pushes the organization in a direction the group wishes. A pull process instead allows the people in the organization to react to new ideas.
Now Scrum is in a way a push process, the prioritizing and decisions on What to do is done by the PO. How would a team process look like if it instead was a pull process? A process where you attract, access and achieve. Where the contribution of the individuals decide the trajectory of the value generation. Instead of a governing Product Owner who points in the direction the product should move.
How does the concept of profit work in this scenario? The normal approach to payment probably will not work as you want to attract a wide amount of inspired people. Money might be limited, and typically traditional payment methods imply a push model. Since you want to send your money to just one person. The distribution of payment should be handled in the pull platform.
Naturally the resulting product should be open for contribution and or extension somehow.
Just some thoughts for now.
My presentation at AS2010
Posted by Morten in Uncategorized on May 15, 2010
I held a presentation at AS2010 about handling defects. The slides are up, unfortunately there is not text in the slides and there’s no audio track… but for those who wish to see my slides you can find the at:
Inventory in software
Posted by Morten in Uncategorized on May 5, 2010
I’ve been thinking a bit about all these factory references that occur when discussing software development. So here is an inventory management view, I guess.
Inventory, viewed from a lean perspective is waste. If you can keep your process running with minimal inventory, then you can decrease costs for changing the process.
Software is immaterial, so there is no “inventory” per se. But, there are equivalent cost scenarios.
Here are a few examples of inventories that occur during software development:
- Documentation
- Versions of the same software in production
- Source-code
- Issue tracking systems
I’ll describe the cost scenarios for these examples, there is probably more.
Documentation
As soon as you write your documentation, it starts aging. Documentation, be it help documents or documents describing the system, are like groceries. They go old, and they do so in different rates. Some documentation is more resistant to change while other gets outdate faster than you can write it. This implies a maintenance cost for documentation, either keep it up to date or throw it out. The cost of someone using old documentation could be very expensive.
Versions of the same software in production
A favorite of mine. Every version you have in production has its own personality, it’s own quirks, features, bugs and what not. This implies greatly increased support costs.
Source-code
Source-code is also a sort of inventory. The more code there is the more there is to maintain. Sure you might not change the code all that often, but unless your code is separate products, it interacts. Larger code-bases require more testing (be it automated or manual testing). Good design helps reduce the size of the code base, and from a cost perspective keeping the codebase low is very important.
Issue tracking systems
Issue tracking systems is just an inventory of reported issues. As it grows the cost for maintaining the issues grows. Every release has the potential to solve any issue, which could at worst imply workload on developers to keep, not only the source-code and documentation up to date, but also the issue tracking system. Secondly, if it takes too long between something being entered into the tracking system and it being fixed. Then the people, stakeholders, for that issue have forgotten about it or worked around it in some way. Also most of the time, the act of managing and tracking the issue costs far more than just fixing it.
Reducing inventory
So what to strive for, only keep documentation for which you commit to writing and maintaining. Have one version of the system in production, and get mechanisms into place to quickly update all clients so you can keep it so. Keep your code-base small, strive to solve problems using better design and less code. Think more, code less. Last but not least, fix problems as they occur, strive for zero-defects. If your using Scrum you can handle issues in a sprint, but avoid long-running tracking.
Measuring defects
Posted by Morten in Uncategorized on May 3, 2010
I was working on performance tuning for the mobile client of RemoteX Applications when I found a tool called EQATEC Analytics. Six month later I added it to our clients for the first time.
EQATEC Analytics is quite interesting, for RemoteX it solves an interesting issue. Error reports are hard to collect from Compact Framework devices, especially since all error messages state that “we’re missing the translation pack to translate these errors, thus you get this crappy errors message instead”.
EQATEC Analytics captures all unhandled exceptions and report them back to a server application for analysis. This means that all crashes are reported so they can be analyzed by us, without involving the user in the information collection process. (no personal information is sent to the server)
The benefits of this enormous. We can see the quality trends of our applications (at least when it comes to crashes), and fix the errors that occur the most.
Traditionally the errors are fixed based on the information received by customers, manual error reports and what not. Relying on this type of information means that you fix the errors that most people report, or the errors you can reproduce. With EQATEC Analytics you, you can get an exact stack trace indicating the problem area, and depending on how you configure it to work you can also request information regarding what was happening during the crash.,
It also provides an excellent way to see if our efforts of improving the quality of the product is helping or not.
Now it also has features to collect information about what kind of system our applications are run on, and also collect statistics of which features are used in the applications.
We’ve used EQATEC Analytics in production since January 2010 and so far we are very happy with the results.
An interesting note here is that the next version of Shuffle will use a similar tool for Android, called Flurry.
Troubleshooting
Posted by Morten in Uncategorized on March 23, 2010
Sometimes I’m amazed. I came to work this morning, and someone came at me in slight panic. A system that is central for our customer operations is having an outage what do we do.
Apparently what they had tried to isolate the problem was checking again and again if the system was working. Basically just trying to refresh in the browser.
What they hadn’t done was to try to troubleshoot it.
How do you troubleshoot?
You isolate all other components that can fail and follow the error as close to its source as possible.
I came in isolated one piece of commodity technology between them and the service they were trying to use. And voila it worked.
The piece taken out, the handset. Once plugged back in the handset worked again.
One of the most important aspects of solving any problem is to isolate it. If you don’t; every attempt at solving the problem is just guessing or brute force hammering on the problem (brute force attempts have a high risk of breaking stuff and a less of a chance to solving any problem. Sometimes however, it just feels good)
Alt.Net Code sparring session
Posted by Morten in Uncategorized on December 14, 2009
Last week we had a code sparring session in Stockholm under the flag of Alt.Net Sweden.
Peter Hultgren, also a member of Alt.Net Sweden came up with the idea. During the Coding Kata held a few weeks ago at Avega we identified a few problems with the setup.
one of the problems identified during the coding kata was that a lot of people were idle, or non-productive. There was a lot of discussion etc. all due to the fact that there were 8 people and 1 keyboard.
With the code sparring setup there is a set up of 2 people per keyboard (maximum of 3). Meaning several different solutions. We also published which kata we were going to do in the invitation so no time would be wasted on deciding what to do.
RemoteX hosted the session at the new office, offering Beer and Pizza to the 11 participants. We did the Yahtzee kata, with 20 minute rotations. With 5 people stationary at their own computers, so everyone providing a computer felt comfortable with doing so.
This meant that we could have a full rotation in the given time frame.
As far as I could tell everyone had a good time. Of the 5 different solutions here were a few quirks:
- one was implemented in python
- one was implemented using BDD through NBehave
- one used NUnit
- one used NUnit in MonoDevelop on a Macintosh
- one used MSTest
It was quite interesting to see the different setups, and solutions.
Some reflections:
The Yahtzee kata was a bit too simple to produce any interesting variations. Perhaps if it had been set up with Object Calisthenics it could have resulted in more variation.