Now when my commute went from 10-20 mins to 30-40 mins in each direction I quickly burned the backlog of podcasts. I gave a try to some new and so far I like what I hear. Here they are:
What are some of your favorite podcasts?
Weekend listening: a couple of interesting podcasts
Posted in Weekend reading Tagged Business, Management, Podcast, Software, Software engineering Leave a comment
“Can you endorse me?” considered harmful
Every once in a while you receive “Can you endorse me?” inquiries in your LinkedIn Inbox. There is something which I do not like about such requests, if they come without recommendation for you first. It is like saying “I’ve worked with you long enough that you recognize value of the work I’ve done, which also means that I can do the same, but I do not really think that you contribution is worth my recommendation. Can you endorse me?”
In fact, your recommendation of someone is the best request for endorsement. Indeed, why do you want an endorsement from person, whom you do not respect enough to give your own recommendation. It is not better than asking a stranger to sign a petition that you are the smartest person in this street.
And remember: the one, who cares most (about the other), gets most out of relationship.
Inducing a change
I’m currently working on site with client. The other day I had a conversation with one of the project managers and somehow we landed on a topic of inducing a change in organization. Especially, when the change needs to be supported by management and management is not very supportive, because the problem is not very high on the priority list.
Depending on the actual environment and type of change involved here are two strategies that might work.
Get allies. Often times you and your fellow colleagues feel the pain, know the problem and see the solution, but management does not really understand what it is that you are trying to solve and therefore is reluctant to support you or allocate funds needed to implement change. What you can do it to get an ally, who shares your vision and is willing to take the problem and solution to the management with you. If two people show up with the same problem, it is easier to get attention and have manager spend time thinking about what you have to say. When you open a meeting you called to resolve this problem with “We’ve discussed this problem with such and such (and those people are in the room) and we are in agreement that solution would be…” it is much easier to get through manager’s internal “why do I care?”
Propose to try. This is based on The Puppy Dog Close approach. Here is how Tim Ferris describes it in The 4-hour Workweek:
The Puppy Dog Close in sales is so named because it is based on the pet store sales approach: If someone likes a puppy but is hesitant to make the life-altering purchase, just offer to let them take the pup home and bring it back of they change their minds. Of course, the return seldom happens.
The Puppy Dog Close is invaluable whenever you face resistance to permanent changes. Get your foot in the door with a “let’s just try it once” reversible trial.
There is psychological resistance to make perceivably big decisions without “proper” consideration, which, of course, never happens if the problem does not seem very important to management. By making the change temporary you lower the barrier for amount of consideration on the change. If the change will be for good, most likely no one will question the decision to make it. And, of course, if change for some reason does not bring the relief, you need to be the first to admit it and revert back to older procedures.
What do you do to induce a change in organization?
(Image by Dina Middin)
SOA Manifesto
Recently I discovered that during 2nd International SOA Symposium they published SOA Manifesto. It follows the spirit of the famous Agile Manifesto, which provoked many discussion and debates over the actual meaning of the statements of that manifesto.
(Not) surprisingly there are many other manifestos related to software. Here are some to name a few:
But there is important thing, which puts SOA and Agile manifestos apart from others — they can not be simply declared by an individual to work. While one can accept, for example, the GNU Manifesto and act as declared and make a difference. With SOA and Agile you can not manifest something individually — the team has to embrace these ideas together in order to make them work.
I wonder when (and if) we will move to team manifestos instead on manifestos of individuals.
A farm and a zoo
Have you ever visited a farm? A farm which produces milk, or meat, or even wheat, or corn? If you’ve been there, I’m sure, you’ve seen many interesting things all over the place: tools and mechanisms, people and animals. I’m also equally sure, you haven’t seen there one thing – variety. Meat farms do not breed cows, pigs, chicken and rabbits. Milk farms do not feature cows together with goats on their premises. Grain farms do not harvest dozens of kind of grain. Instead they specialize in something and they try to stay as uniform as possible with respect to animals they grow, grains they seed and tools they use.
Why do they do that? Because variety inevitably means higher costs of operation, but farms can not benefit from variety. For them it makes a lot more sense to have 200 cows of the same kind, than 100 of one and 100 of another since they require different treatment thus rising the cost of support.
On the other hand there are enterprises, which directly benefit from variety – zoos! The more different species you have in the zoo, the more money you can charge for entry tickets, the more visitors you can attract. Yes, operational costs go up as you add more animals – obviously lion requires completely different conditions than pelican, and most likely you will need two different people with different skill sets to look after them. But since you are able to directly sell this variety to customers, it does not undermine your profits.
So, the difference between a farm and a zoo is in their relation to variety: it kills the farm, but propels the zoo.
We see examples of both in our day-to-day lives. We enter farm land, when we rent a car, call a taxi, use corporate computer, eat in McDonald’s. We go to zoo, when we shop in the mall, eat in the restaurant, buy a vacation tour.
Look at you business, department, or team and see what you are running – a zoo or a farm. Chances are that you are running a zoo, when you should be running a farm. Run a farm unless you really know how to benefit from variety, which zoo has to offer.
Posted in Business, Business analysis, Projections of life Tagged Farm, Variety, Zoo Leave a comment
About productivity in Ukrainian
A friend of mine, Alexander Babich, started a new blog about productivity – ProductivyBlog.com.ua (in Ukrainian). I’ve been following another his another blog for ages and every so often I’ve learned about new useful tools and approaches, which changed the way I do things and changed for better.
If you understand Ukrainian this blog is well worth checking out.
Getting feedback from users
When you work as a Business Analyst, important part you job is to conduct software demos and software reviews with users. User reviews can help a lot to improve quality of your product, but you need to put some effort to ensure efficiency of reviews. Here some some hints on that will help.
First and foremost, you go on those review session to hear users’ feedback, positive and negative. You want to make users tell you what they like, what functions seem to be overly complex, where performance is not up to par. You do not conduct reviews to impress users, to have them breathlessly admire features you demo. You have to come to those reviews with the only desire to hear your users and make your software even better for them.
Be prepared to hear negative feedback and do not try to defend the approach you took to implement certain feature, when users say they do not like it. If you try to defend people will immediately feel that they are wasting time with you, because you do not care about their feedback and insist on you solution, when they call it wrong. Instead, you want to understand, why they think it is a bad approach, and then propose a solution to that. Audience will appreciate your care.
Make sure that your own feedback and comments were addressed before you show anything to users. Nothing can be more frustrating on the review than hearing something that you already know. At least you need to make sure that review participants are aware that certain areas of the product you review fall out of scope of today’s session and they should not pay any significant attention to any gaps there.
Keep audience engaged during the entire review session. When someone makes a couple of comments, he feels like his mission here was accomplished and, as a result, will be less attentive, less willing to interrupt anybody to propose idea. You want to keep everyone in the game, and some tricks from presenter’s toolbox can help you with that.
Posted in Business analysis Tagged Business analysis, Customer Review, Feedback, User review Leave a comment
Intrinsic motivation vs. Extrinsic stimulus
Great talk by Dan Pink at TED about pitfalls of extrinsic stimulus and scientific evidence for intrinsic motivation:
I kind of always felt that way, but now I’ve got evidence to refer to. Plutarch was right that
The mind is not a vessel to be filled but a fire to be kindled.
You can not stimulate creativity, you can only create environment for it to blossom.
Zooming in on a design
Have you ever worked with, maintained, explored a system which looked and felt really great in one area, but was really awkward and clumsy in another one? That was an instance of an elephant on the crutches.
This often happens, when design specification was not consistent in the level of detail for different parts of the system. And here is how this may happen.
When you design a system, it is never going to be plain and the same wherever you look at. If you have a database and a user interface – those two parts are already different enough. Such diversity naturally leads to the fact that there are some parts that you enjoy working on more than others (after all we never like doing everything that we do).
What happens next is that you spend much more time thinking about parts you like (because there you use new fancy technology, or neat engineering approach, or who knows why). Therefore you add more details to design of those subsystems that you really like. The outcome of all of this typically would be a specification that is an elephant with crutches instead of hind legs, because elephant’s butt was never you favorite part of the system and design of this “subsystem” never was detailed enough to make sure it is consistent with the front.
Ideally, your design should be like Google Maps: you should be able to zoom in and zoom out on any part you need. It does not make sense to have a map, which shows each and every tree in your neighborhood, but gives you only a vague idea about how to get to grocery store 5 miles away.
When developing and documenting design you should gradually and consistently increase level of detail in your specification. Ideally, difference in granularity of descriptions of different parts between any two parts of the system should never be more than one level. One possible way of zooming in would be to describe
This is not the only possible way to zoom. However, when you have class diagram with methods and their parameters, but do not have stored procedures defined for your database, you are doing something wrong (or, hopefully, your design specification is not complete yet).
Design specification is only useful when it can help you answer questions you get during development. This essentially means that you should be able to navigate it and find things – which is zooming in and out and seeing enough to make the right turn.