reading: maister

Posted by anton
on Saturday, July 25, 2009

managing the professional services firm is my second book on consulting (first one being weinberg’s secrets of consulting).

i have been resisting the temptation to gobble up the whole book in one sitting. i am taking it slowly, giving myself time to think through each chapter, since every one is loaded with so much insight and relevant quotes, that at times i even get frustrated, not able to take it all in.

it has it all – from marketing to clients, finding work, to running a consulting business, motivating and growing people. i am only half-way through, but i am tempted to label it as a required reading for anyone starting in consulting.

here’s a quote from “motivational crisis” chapter:

Are professionals different from other types of workers? Do they need to be managed (and motivated) in special ways? While it is difficult to support the assertion that all professionals are different from all other workers, my work has led me to suspect that, when it comes to motivating forces, the average professional is different from the average worker in other environments: a difference based, I suspect, not on such things as educational levels, but on the psyche of those who choose professional careers.

The typical professional is apt to describe him or herself in the following way: “I am the type of person who gets bored easily. I hate doing repetitive sorts of work, and always like to seek out new challenges. Once I know I can do something, it tends not to satisfy me anymore.” This is, of course, a somewhat self-flattering description. In my experience, however, it is an accurate one. Professionals, certainly the best among them, are constantly driven to seek out the new, the unfamiliar, the challenging. The key word here is driven.

People who feel the (neurotic?) need to constantly and repeatedly test their skills against unfamiliar problems with an uncertain probability of success are frequently insecure, with a low sense of self-worth (never expressed in public), in constant need of external tests of their merits to prove (to themselves) that they still “got it.”

Many professionals, I would assert, are prime examples of what is now termed “The Impostor Syndrome”—successful people who live in constant dread that someone will, one day, tap them on the shoulder and say “We’ve found you out. You’ve been faking it all these years.”

Because of this, professionals tend to exhibit some clearly defined behavioral characteristics. They require continual challenge and personal growth to retain their interest, and are impatient when they do not receive it. They constantly ask themselves, and their superiors, “Am I still on track?” Because of their insecurity, and the ambiguity that surrounds the definition of “good work” in professional contexts, they need quick, repeated feedback on their performance to validate their efforts. They tend to be “scoreboard-oriented”: eager for visible, well-defined measures of success that can reassure them. They like to have unambiguous goals to shoot at. From their need to achieve self-respect by receiving the respect of others, it follows that professionals value both autonomy in their work and involvement in policy decisions, whether on engagements or firm-management matters. As much as these “rewards” are valued in their own right, they are valued more as signs that the organization trusts and respects them.

the essential drucker

Posted by anton
on Monday, April 13, 2009

perhaps it is my destiny to stumble into things that i should have known (and probably have known at some point, but they only became relevant now). in any case, i am happy to add drucker to my pantheon of striking bald men (already staffed with the likes of foucault, seth godin, and crowley).

i really enjoyed this updated/revised “best of” collection of drucker essays. he is not instantly quotable – i do not think he goes after the effect of catchy parables, so it is hard to pick out the pearls to quote here.

but of course, i cannot resist:

[...] the three stonecutters [...] were asked what they were doing. The first replied, “I am making a living.” The second kept on hammering while he said, “I am doing the best job of stonecutting in the entire county.” The third one looked up with a visionary gleam in his eyes and said, “I am building a cathedral.”

perhaps proverbs and fables are a retreat for those that cannot come up with an original wording themselves, but dammit, this is the kind of stuff that you hit people over the head with to get your idea across.

anyway, i really liked his writing on building innovation into the organization. his essays on the place of the organization in the society were also quite eye-opening, especially with respect to the non-profits. he does not go into heavy theorizing – everything is quite high-level and appears simplified, but there are a lot of good observations, especially once you read them in context. yes, some of it is a bit dated, but it is easy to make a quick mental adjustment to see the core of what he is getting at.

i’ll have to pick up a few more of his books; at this rate i will be reading f. w. taylor in no time. oh boy.

reading: team dysfunctions

Posted by anton
on Monday, July 28, 2008

my work-related reading started with programming books and reference materials. then, as i was becoming more aware of things around me, i started reading up on development process, requirements gathering, and all this other “softer” stuff.

when it comes to applying the knowledge, the latter was more tricky – perhaps because it was not just up to me when and where to implement it – other people had to be involved.

with non-technical books it is all too easy to kick back and follow along as if reading an adventure novel – this stuff is engaging, and one might dream of making bold decisions, only if one were in the position of power – all of it from the safety of one’s couch.

in my case i realized that i had to consciously make a mental effort to move from mere recognition and acknowledgment to tangible steps – what can i do tomorrow, in my particular environment? otherwise it will just sit in the back of my mind, and i will mumble behind peoples’ backs recognizing yet another opportunity missed.

this seth godin’s blog entry really helped to illuminate this problem for me – the ideas in a book are just a short bullet list, the rest is persuading the reader to act. so i will follow his advice and pick a book from my recent reading to see if i can get something tangible out of it:

five dysfunctions of a team – is a light read, just a few simple points presented first as a novel, then discussed one by one. but then after reading it, as it was fresh in my mind, i gradually noticed how nicely they applied to the environment around me.

true to its title (admittedly catchy), the book goes over five qualities that are necessary for creating an effective team; they build upon each other, so i’ll pick the first three, since they are the foundation for the rest:


in the team-building context trust is knowing that all the team members have team priorities first in their agenda. it is not being afraid of showing ones’ vulnerabilities, knowing that others won’t take advantage of that. it is knowing that your peers’ intentions are good, and there is no reason to be protective or careful around the group.

trust makes delegation possible – which allows the team to scale and be more effective, as work gets distributed around with everyone aware of individual strengths and weaknesses within the team. the opposite of that is everyone working in their little cubbyhole and reporting up.

finally, trust makes risk taking possible.

i think i consciously made an effort a few years ago to make sure i say, “i do not know” more – this simple acknowledgment goes a long way towards removing barriers within the team. it makes offering help and asking for help possible (which is good telltale sign in itself).

another conscious effort was to apologize more – it works towards defusing the tension and focusing on the problem. obviously, one has to be somewhat self-aware for that to work, and luckily i had a misfortune of witnessing some monstrous examples of personal communication deficiencies, so i have learned from others’ mistakes as well as my own.

team identity

in school we are encouraged to focus on individual goals, so it takes a conscious effort to change that habit for the good of the team, and team identity is one of the powerful aids. one has to consciously build it up – starting from the name of the team, clear statement of short-term and long-term goals, the vision that provides perspective when you are saddled with everyday tasks, acknowledging successes and being proud of them, sharing the problems and treating them as team’s responsibility. there are plenty of smaller things – everything from eating lunches together to casual chit-chat.

secrets and politics within the team kill trust, so my personal resolution is to be more open – have no reservations about telling others what i am working on and why. i noticed that i do hold back sometimes, not sure of others’ intent, and this is definitely a problem.

i also need to give more benefit of the doubt before arriving to conclusions regarding others’ motivations, i think sometimes i am too eager to assume ill intent, and this obviously inhibits trust.


this is the next step, it might come naturally as a result of working together, but it helps to acknowledge and strive for it consciously.

the good thing is that large companies invest heavily in HR review processes. the sad thing is that for the bad manager these twice a year reviews make the situation even worse, since they come across as stilted corny HR drone-induced formalities, so anything that resembles them (like actual good feedback) is squashed even further. as for the good manager, they do not need these, since they do it on regular basis anyway.

so my personal resolution is to give more feedback to my peers (which i think i am getting better at – noticing individual achievements, taking the time to stop by and comment on something casually, etc), but also giving feedback to my management, which i am not that good at.

i think i also need to get better at offering help – taking into account the personalities of others and trying to tailor my offer to that.


productive conflict is essential. if it is avoided, important issues would not get resolved, which will be even worse in the long run. so one must recognize its importance and embrace it, at the same time remembering that it should not be personal.

needless to say, without trust productive conflict is impossible.

i think this is where i could use a lot of work. at some point i became all too aware of others’, so i tend to come across as non-confrontational more and more. i often tend to avoid conflict in the misguided attempt of maintaining everyone’s comfort.

another problem is “picking your fights” – there are always plenty of problems, and one cannot tend to them all. so you either spend your time on all of them and accomplish nothing, or give up and let it all slide.

here’s a common scenario i am guilty of – something is wrong, something is not working, i try a few times to fix it, but it is not my responsibility, although it hurts me as much as the others. so i grumble half-heartedly around the people responsible, but never challenge them openly.

a natural reaction is to ignore it, but that leads to the “broken windows” syndrome (see pragmatic programmer), which, once it gains momentum within the team, is hard to reverse.

it also reinforces the silos – this is my own perch, i tend to it, and others’ should not stick their heads in. ideally, a problem will be out in the open, the whole team would regard it as their problem.

so instead of creating a permanent state of team guilt, perhaps these issues could be put out in the open and prioritized, so that at least these mistakes won’t be made again.

i also primarily worked in the teams where i knew that we could always solve problems ourselves, there was no need to reach out to “higher authority.” it turns out that in large organizations it is sometimes necessary to ask for arbitrage from above to get stuff done. although it pains me to do this, since it fundamentally goes against what i think a leader should be doing, i have to acknowledge the reality and focus on the problem that needs to be solved.


ideally i want and environment where my teammates hold each other responsible for the high standard of work they produce as a team. if someone goofs up, others should be able to step in and challenge them.

here’s an example. given a multitude of assorted projects with various infrastructure problems, one is tempted to create an architectural police of sorts that goes through the checklist – proper logs are written and rolled, monitoring in place, DR in place, etc. while this could be a valid first step in some situations, in a perfect world the team itself will know what these standards are (perhaps since they are wikified) and their personal pride and identity as a team makes them follow these standards and make sure other teammates follow them as well.

it comes natural in a healthy teams, but in dysfunctional teams its absence is painfully obvious: everyone does just the bare minimum to get by, and only certain people in complete isolation try to achieve their own high standards.

peer pressure is a powerful thing – poor performers feel the pressure to improve; it promotes respect, as opposed to resentment between team members with different standards.

of course it builds on the previous principles – it is impossible without trust to give feedback, it is impossible to challenge people with fear of conflict.

so my personal takeaway, going back to fear of conflict, is to challenge people and speak up; i should collect and promote best practices; i should be doing more presentations and knowledge sharing.

it is a gradual process, and with the absence of slack this grass-roots movement is very hard, so at some point there needs to be some management support.

it also helps to hold project retrospectives, because if we lack self-awareness and succumb to “broken windows”, we will make the same mistakes over and over again and take it as a norm. i am guilty of not pushing for retrospectives as much as i could. perhaps as a start i can informally round up a few teammates and go through a few exercises suggested by the “agile retrospectives” book.

why am i so adamant on this being a peer effort? leaders should not be the ones creating accountability, in fact it can be counterproductive – the team will delegate the responsibility to the leader and as a result either become even more passive, or worse, turn against it, seeing it as unnecessarily imposed upon them.

there is a lot more practical stuff in the book, and skimming through it again makes me realize that i’ve missed quite a few tips, but let’s see if i can get some of these practical things done first.

hiring technical people

Posted by anton
on Monday, August 06, 2007

as an addendum to previous post: although i mentioned one of the johanna rothman’s articles in the list of links, she really warrants a separate mention.

i really, really liked her manage it! book (published by pragmatic programmers). at first it seemed a bit dry, compared to weinberg’s writing (he contributes an introduction), but the feeling goes away after a few chapters.

i just feel so comfortable with her take on project management – there is no agilist zealotry or flashy theatrics. she is indeed very pragmatic – she acknowledges different organizations and different projects and teams, she introduces options and alternatives and explains the reasons for each. there are practical tips as well as a larger overall motifs that drive them.

but back to subject of this post – a few weekends ago i spent a whole day combing through her excellent hiring technical people blog. once again, it is perfectly pragmatic, i especially enjoy her style as she explores the ideas, not necessarily presenting them as truths handed down from above.

compare this with joel – he recently cleaned up and released his writing on hiring (smart and gets things done – which i already purchased). i really appreciate many of his ideas, and i think he’s done a great service to the industry by popularizing them, but i do not find myself trusting him fully as a reader – there is too much glitz and posturing, desire to shock and awe. plus he keeps forgetting about being humble – he is an owner of a boutique software company – he is damn good at what he does, but it means just that.

in any case, i have ordered johanna’s book on hiring technical people. she also co-authored another book on project management from pragprogs – behind closed doors: secrets of great management, which i am yet to read.

finally, her site contains another blog on project management, as well as a collection of articles, links to her guest blogs on other sites, etc. she is also a regular at annual amplifying your effectiveness conference, which i really should be going to.

reading: weinberg

Posted by anton
on Sunday, March 11, 2007

I am a little concerned that this space does not see much of the technical content in past few months. One of the main reasons is that the stuff I spend most of my energy on (and also the area where I currently learn the most) is organizational - everything from project delivery to team dynamics. It is surprising how much of it is dysfunctional, so all the reading that I have done in the past and seemed only marginally applicable now becomes incredibly relevant, supported by real-life examples.

One of the books I really enjoyed recently was Jerry Weinberg's "Becoming a Technical Leader." Very down-to-earth and personal book that is pragmatic, relevant, and simply rings true. Here's a couple quotes:

So perhaps a better leadership question is this:

If you had to take a trip with someone else driving, would you prefer a driver who
  1. has never had an accident, but would likely be indecisive if an accident occured
  2. has had an average of one accident a week, but was very adept at making decisions in emergency situations

Sad to say, many people seem to prefer (2). That's why Armistice Day has been replaced by Veterans Day. Peace is more difficult to organize, but war is more heroic. Really good organizing seems to lack drama.

Why is it that we reward programmers who work all night to remove the errors they put into their programs, or managers who make drastic organizational changes to resolve the crises their poor management has created? Why not reward the programmers who design so well that they don't have dramatic errors, and managers whose organizations stay out of crisis mode?

Organizing is not about solving problems, but avoiding them. Once you're in the throes of the problem, it's too late to do really effective organizing. Perhaps the biggest obstacle to effective organizing is our eagerness to reward ineffective organizing.

And another one:
A problem-solving leader's entire orientation is toward creating an environment in which everyone can be solving problems, making decisions, and implementing those decisions, rather than personally solving problems, making decisions, and implementing those decisions.

This is where I probably struggle the most in my current team (for many reasons) - giving away trust to acquire trust; in other words, delegating (the book has a whole chapter on it).

Weinberg's "Secrets of Consulting" is next (kudos to Muness for pointing him out to me).

list of books

Posted by anton
on Friday, June 09, 2006
Since our team at work has just been formed, we were asked to submit a few things that we should get, one of them being a list of books. The team does application/integration architecture and implementation. Below is the list I came up with in half an hour, escaping work on Friday night. A lot of these are available on Safari, but since most of these books are technology-agnostic (i.e. not reference texts), they age well, and therefore should reside on a bookshelf.
Must read/must have:
- Enterprise Integration Patterns : Designing, Building, and Deploying Messaging Solutions (0321200683)
- Patterns of Enterprise Application Architecture (0321127420)
- Peopleware : Productive Projects and Teams, 2nd Ed. (0932633439)
- The Best Software Writing I: Selected and Introduced by Joel Spolsky (1590595009)
- Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity (1590593898)
- Refactoring Databases : Evolutionary Database Design (0321293533)
- Working Effectively With Legacy Code (0131177052)
- Service-oriented Architecture : Concepts, Technology, And Design (0131858580)
- Enterprise SOA : Service-Oriented Architecture Best Practices (0131465759)
- Enterprise Service Bus (0596006756)
- The Pragmatic Programmer : From Journeyman to Master (020161622X)
- Refactoring : Improving the Design of Existing Code (0201485672)
- Head First Design Patterns (0596007124)
- The Mythical Man-Month: Essays on Software Engineering (0201835959)
- Design Patterns: Elements of Reusable Object-Oriented Software (0201633612)
- Rapid Development (1556159005)
- Hackers and Painters: Big Ideas from the Computer Age (0596006624)
- Service-Oriented Architecture : A Field Guide to Integrating XML and Web Services (0131428985)
- Applied Cryptography (0471128457)

Very good/really should own:
- Agile Software Development (0201699699)
- Extreme Programming Explained : Embrace Change (0321278658)
- Practices of an Agile Developer : Working in the Real World (097451408X)
- Agile and Iterative Development: A Manager's Guide (0131111558)
- The Inmates Are Running the Asylum : Why High Tech Products Drive Us Crazy and How to Restore the Sanity (0672326140)
- Behind Closed Doors. Secrets of Great Management (0976694026)
- Ship it! A Practical Guide to Successful Software Projects (0974514047)
- The Art of Project Management (0596007868)
- The Timeless Way of Building (0195024028)

- Thinking In Java (0131872486)
- Planning Extreme Programming (0201710919)
- Test-Driven Development : By Example (0321146530)
- Why Business People Speak Like Idiots : A Bullfighter's Guide (0743269098)
- Effective Java Programming Language Guide (0201310058)
- Domain-Driven Design : Tackling Complexity in the Heart of Software (0321125215)
- The Psychology of Computer Programming (0932633420)
- John von Neumann and the Origins of Modern Computing (0262011212)
- The Art of Software Testing, Second Edition (0471469122)
- Punished By Rewards: The Trouble with Gold Stars, Incentive Plans, A's, Praise, and Other Bribes (0618001816)
- The Cluetrain Manifesto: The End of Business as Usual (0738204315)
- Data Crunching. Solve Everyday Problems using Java, Python, and more. (0974514071)
- The Algorithm Design Manual (0387948600) 
Probably there are a few that I am missing, especially in the non-tech department. Some of these are also listed more for the culture shock value, to get people thinking. Also, these are not developers' books per se, considering that folks should have a developer background and the nature of the group's work.