Some Thoughts on Manipulation
- Other person wants you to do something (which is not necessarily a bad thing).
- She wants to make you do it in a sort of "covert" way, which I would generally call a bad thing in professional environment.
When it comes to response to manipulation, all things being equal, I would have a conversation with a person saying something along the lines of "Hey, I've noticed that you try to trick me into something and don't like you doing that. If you need something from me, let's discuss, but don't try to trick me."
This kind of feedback serves two purposes: (a) letting other party know that you've noticed manipulation and don't like it (who does?); (b) showing a better way to do business with you. If a case is not helpless, this should help.
What do you do when somebody tries to manipulate you?
On Corporate Culture
Merlin Mann on corporate culture in "Back to Work" #17:
Living inside brick building full of lies.
AgileBaseCamp in Dnipro in July
On July 2nd join me and hundreds of other software professionals in Dnipropetrovsk on AgileBaseCamp. Speaker line-up looks great — do not miss it! I'll share some of my ideas on why you do not necessarily need to do all the things you think you have to, and how Schrödinger's cat can help with that.
Just Do It - Agile PechaKucha vol.2
Last week I gave a talk about importance of doing what talk about at Agile PechaKucha vol.2 in Kyiv. Here is slidecast from my presentation (in Russian):
Check out the rest of the presentations from that evening. See you on the next event!
Two types of answers
When I'm asked a question, my reply often is "Well, there are two answers to that question: a short one and a long one (or a simple and complex)..." And that is because there are indeed two types of answers to many questions. I would call them definitive and process oriented. For example, "how long will it take to complete this project?". The simple answer might be "we do not know", the complex answer will be "we do not know, but here is how we can control and manage schedule for our project and make it possible to make certain commitments on dates depending on your goals".
Another perspective on these answers is that one of them is like "here it is" and another one is "oh, here is how you get it".Remember that saying that professionals do not always know all the answers, but they always know how to find what they need.
The matter of fact is that process oriented answers are just as important as definitive replies. Of course, we should always starve to simplicity, but if there is no simple solution, we should not abandon looking for complex ones.
CEE-SECR 2010
Official call for papers for CEE-SECR 2010 is now available. Submission deadline is May 24 - a little less than two months from now.
QUOTE: Heroics in the workplace
...People respond with heroic behavior. And when they act heroically, they stop improving. They just act heroically again, again, and again, and they stop learning.
David Anderson in interview for Software Engineering Radio.
Your app vs. GMail
When you work in what I call a "controlled environment" it is kind of easy to be dragged into compromises in different areas of quality of your products. As with many other things it does not necessarily happen because you want to compromise, but simply because you can do that.
There are many implicit myths about controlled environments. Here are just a few:
- In controlled environments users have to use your software and therefore you can compromise on usability and user experience. After all users to not have alternatives to in-house corporate software tools.
- In controlled environments users have to use your software and therefore you can compromise on performance tuning. After all users to not have alternatives to your software.
- In controlled environments it is ok to provide something "good enough" software simply because all the other corporate software users have got on their computers is crap.
None of that is actually true nowadays. Every corporate user also uses GMail for his personal e-mail. Every corporate user also uses Mint.com to manage his personal finances. Every corporate user also uses Flickr to organize his photos.
We all know that expectations are set by previous experiences, especially, when it comes to non-functional requirements and qualities, which are hard to quantify, like usability. Users have already seen what is possible in other apps and they want to be able to get to the information managed by your apps in a matter of a few keystrokes, like in GMail. They want your apps to produce relevant and nicely looking reports, like on Mint.com. They want easy access to functions they need while focusing on the main thing they do, like with Flickr.
When developing corporate app you compete with Google, Intuit, Yahoo. In modern world you do not have benefit of controlled environment and you have to compete for users' attention and buy in. These days the best recognition for corporate software engineer would be when user while working with custom corporate software system says "Wow! I wish GMail had this too..."
Metrics that mean
We all know this law coined by Elia Goldratt:
Tell me how you’ll measure me, and I’ll tell you how I’ll behave.
This cause-consequence relationship between incentive and action is very important for managers. As with many other things this can be applied on different levels. Consider the difference of measuring someone by number of oranges sold versus number of happy customers returning to the store to buy oranges.
I came across a great example of metric taken to the next level in post £24m School Can't Get Its WiFi Working by Fraser Speirs:
In my school, we aim to lose no more than five teaching hours per school year to computer failure.
Do you see how this metric not only prompts "correct" behavior, but also sets the goal? Metrics like this are less prone to "local optimum" problem when person compromises on quality and results in some other areas make up for particular target, because they do not control action itself (like, selling oranges), but instead control ultimate outcome of the action (like, happy customers).
Are you and your team starve to get more happy customers or try to sell more oranges?
Webinar: The Business Driven Software Development
Net Objectives conducts a series of webinars on Business Driven Software Development:
This series provides an introduction on how to achieve Business Agility. Business Agility enables an organization to respond quickly to external forces (such as new market opportunities and competitive forces) as well as to respond quickly to new insights attained internally. While many organizations have achieved the local optimizations of more effective teams, few have achieved agility at the organizational level. Even when team agility has been achieved, if improvements to how the business is selecting their product enhancements isn’t done, overall return on investment of software development may not have significantly improved.
First event is tomorrow at 9 AM PST. Register at the event page to attend the webinar.