They should not complain if...

Every project and team always has issues. I'm a big fan of making things better. No one wants to hear complaining (not to be confused with constructive criticism or a call for action). Here's a brain dump of when people should not complain:

• They don't have a better alternative
• They can't specify what the actual problem is (saying "something seems wrong, but I don't know exactly what" isn't complaining)
• If their manager asks "what can I do", and they can't tell them
• They caused the problem
• They were warned, and did it anyway
   

Migrating blog

I've officially migrated my blog from .Net Developer's Journal (http://www.timstall.dotnetdevelopersjournal.com/) to my own domain - http://www.timstall.com/. .NDJ dropped their blogs, so it was inevidable.

It was an interesting technical adventure - I decided to use blogger based on some friend's recommendations, and was pleased with their API - it just worked:
http://code.google.com/apis/blogger/docs/2.0/developers_guide_dotnet.html#CreatingPublicEntries

I was able to set titles, publish dates, suggested Urls, and even dynamically add categories.
I could then write a simple app that posts 40+ entries a day (Blogger only allows a certain limit, so I couldn't do all 500 posts in an hour), so I made the migration tool run over several days.

[UPDATE] I added a page: http://www.timstall.com/p/timstalldotnetdevelopersjournalcom.html to help redirect traffic.

How does a techie know when they're learning the business?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/how_does_a_techie_know_when_theyre_learning_the_business.htm]

Obviously there's a gradual scale, but here's a brain dump:

• You can talk to a non-tech person without using tech speak (Your business skills are strong enough that you don't need to "hide" behind your tech skills to bail you out).
• You can list at least three industry-specific success metrics (besides standards like "revenue" and "profit").
• You can use business decisions as a "tie-breaker" between technologies.
• You can prioritize features and defend your reasoning.
• You know why your CEO or supervisor is upset.
• You know where your revenue comes from, and how it flows through the company’s various systems and departments. Looking at the production database (that records transactions), you can make an educated guess if this year was financially better than last year.
• You can read the year-end report.
• When a new boundary case comes up in the code, you can make an educated guess before verifying with the business analyst. Then you send the business analyst (BA) an email like "I think it's X because of A and B, would that be right?", and the BA can just reply with a "yes" instead of a detailed email correcting all your concepts.

Secrets to Winning at Office Politics - Part 2

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/secrets_to_winning_at_office_politics__part_2.htm]

Following up on my previous post, here are several good quotes from the other chapters of the very good book, Secrets to Winning at Office Politics.

Chapter 4: Political Psych 101: Allies and Adversaries

• "Positive relationships build political capital." (pg. 53)
• "Allies can be grouped into three categories: Friends, Partners, and Connections." (pg. 55)
• "colleagues usually judge your personality and your competence separately." (pg. 55)
• "Those who loudly complain that 'it's who you know' are usually the same ones who never take the initiatives to get to know anyone." (pg. 59) --> as an introverted hermit, this hits home with me.
• "adversaries fall into three groups: focused, emotional, and vengeful" (pg. 63) --> you want to be aware that someone who seems adversarial because they're just focused on their goal is not necessarily out to get you personally.
• " is not an adversary - [they're] simply a difficult person." (pg. 67)
• "Usually, the most effective containment strategy [with adversaries] is to increase your leverage." (pg. 68)

Chapter 5: Political Games: Moves and Countermoves

• "Political games re played for emotional rewards" (pg. 83)
• "Political game players always have a socially acceptable explanation for everything they do." (pg. 83)

Chapter 6: How to commit political suicide

• "If you want to commit political suicide, simply start engaging in any behavior that consumes a disproportionate share of management's time and attention." (pg. 107)
• "Once people arrive at a conclusion, they unconsciously continue to gather evidence that supports their opinion." (pg. 109)
• "There are four common causes of career destruction: (1) poorly controlled emotions, (2) a victim mentality, (3) self-centered foals; and (4) foolish reactions to change." (pg. 110)
• "Many political suicides are so caught up in their own concerns or delusions that when the ax falls, they are totally shocked." (pg. 121)
• "It's a heckuva lot easier to blame somebody else." (pg. 123)
• "if your colleagues are happily  and productively engaged while you're fuming with rage, then you need to take a closer look at yourself." (pg. 124)
• "When someone indicates that your behavior is a problem, don't automatically reject that possibility." (pg. 126)
• "When you are trying to recast your image, remember that others will not immediately notice the change in your behavior. If you're waiting for the applause, it may seem awfully quiet for a while." (pg. 127)
• "if you're not the problem, but people think you are, the political effect is unfortunately the same." (pg. 127)

Chapter 7: Power, Power, Who has the Power?

• Don't confuse "power" with "authority".
• "... any strength, carried too far, becomes a weakness." (pg. 137)
• "Here are some questions to consider in determining a person's power level: ... Do they talk more about the past or the future? ... Who can they go see without an appointment? ..." (pg. 137)
• "Some timid souls, fearing that they will be perceived as pushy, overbearing, or insensitive, simply give their power away." (pg. 138)
• "If you want to look ridiculous, just try using power that you don't have." (pg. 140)
• On pg. 147, the author presents a 2x2 "Power Grid":
  • High level of position and high degree of influence --> Power Players
  • High level of position and low degree of influence --> Empty suits
  • Low level of position and high degree of influence --> Persuaders
  • Low level of position and low degree of influence --> Weaklings
• "An organization's culture is largely determined by the beliefs, values, and preferences of the Power Elite... you must adjust to the culture established by the reigning Power Elite. There is not one chance in a million that you are going to change it." (pg. 149)

BOOK: Secrets to Winning at Office Politics - Part 1

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/book_secrets_to_winning_at_office_politics__part_1.htm]

I am more of a clumsy walrus than a suave politician, so I was fascinated with the book Secrets to Winning at Office Politics. The author conveys her points with hard-hitting stories, 2x2 windows (to show the whole context), and explicit principles. Probably one of the five best books I've read.

At least twice each chapter, I smacked myself in the head, saying "D'oh - that's what I did wrong in that situation". A general theme of the book is that politics aren't necessarily dirty and corrupt - having good political skills can actually be a service to your coworkers because you can be easier to work with and help them achieve their goals.

There were so many good quotes, that I'm splitting it into multiple blog posts.

Chapter 1: Politics is not a dirty word

• "Our hope was that we could keep him from destroying his career."
• "...keep them from becoming their own worst enemy" (pg. xvii)
• "'politics' is what naturally happens whenever people with different goals, interests, and personalities try to work together." (pg 3)
• "...not everyone is interested in promotions. Autonomy, security, responsibility, skill development, challenge, and interesting work are a few of the other rewards that people often hope to find through their jobs." (pg 5)
• "...it's pretty tough to find tutoring in office politics." (pg 6)
• You must be able to answer the question: "How would you like things to be different?" (pg 7)
• "Wishing is a passive activity that can easily degenerate into whining and complaining. Goals, on the other hand, help to define the actions we need to take." (pg 9)
• There are four political types, behavior that (pg 11):
  • Helps your business and helps your personal goals --> winner
  • Helps your business and hurts your personal goals --> martyr
  • Hurts your business and helps your personal goals --> sociopath
  • Hurts your business and hurts your personal goals --> dimwit
• "Never advanced your own interests by harming the business or hurting other people." (pg. 17)

Chapter 2: Political Intelligence and the facts of life

• " wondered why every place he worked was filled with stupid, incompetent people." (pg. 24) --> Sure there are bad companies, but after 10 years and 3 places, if everything is still bad, you probably need to do some self reflection.
• "Clinging to the belief that the workplace should function demographically will only doom you to frustration and disappointment." (27)
• The organization facts of life: (pg. 27)
  • #1: Organizations are not democracies.
  • #2: Some people have more power than others.
  • #3: Virtually all decisions are subjective.
  • #4: Your boss has control over much of your life.
  • #5: Fairness is an impossible goal
• "The person with the most power wins" (pg. 29)
• "Getting worked up about fairness is a waste of time and politically stupid. People who are obsessed with fairness tend to whine, and nobody likes a whiner... politically intelligent people concern themselves with leverage, not fairness." (pg. 31)

Chapter 3: Forget Fairness, Look for leverage

• "she was pulling a power play at the wrong time" (pg. 36) - with respect someone moving houses, who got angry at the movers and threatened not to pay while they still had all her furniture in their truck.
• "Winners are able to accurately calculate the Leverage Equation in any given situation." (pg. 38)
• "being the boss doesn't necessarily mean that you have the most leverage." (pg. 39)
• "Never intentionally offend anyone at work." (pg. 43)
• "'Fairness' seldom determines what happens to you at work - leverage usually does." (pg. 45)
• "...too much passion can be dysfunctional. Dedication to your work may make you credible and persuasive, but those who are too emotionally invested in their jobs can become defensive and inflexible." (pg. 49) --> I always thought passion was good, but it's possible that good passion can be misdirected for a bad result.

More in the next post...

Change: Incrementally Making Things Better (Part 6)

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/change_incrementally_making_things_better_part_6.htm]

Part 1 (Intro)

Part 2

Part 3

Part 4

Part 5

Part 6

STEP: Finish it

Congratulations, after giving up 2 weeks worth of nightly poker games, you've almost shoved through an improvement that makes your department (and therefore your life) better. So close, but so far. You'll still need to make the final push:

• Walk the users through until completion - Say you wrote an "alpha-widget-escalator" plug-in into Visual Studio that makes development of alpha-widgets 5x faster. Don't just send the team an email saying "please download this tool from the shared drive and install it". No. Pick 3 developers. Go to their desks, and walk them through until it works on their machines and they can use the "alpha-widget-escalator" without you. Or, say you're trying to add code-generation to the build. Don't just give the build team some templates - be prepared to sit with Jill from Change Control Management, open up the build script, and integrate those templates into the build, and then run the build to ensure the templates actually work.
• Show positive metrics to management about the initiative's success - Objective metrics simplify a manager's life because it lets them tell their boss what a great ROI those initiatives have brought. Suppose you created an auto-merger service to merge change sets between branches. Make it track how many files it's merged so you can tell management that it "automatically merged 800 files a month, at an average of 1 min per file, that's saving us raw time of at least 13 hrs a month, and because devs don't manually do this anymore, we're not missing any files, which saves us 10 errors a month, at an average of 1 hr each..." Of course, sparing devs from tedious tasks also increases moral and reduces distractions which lets them remain "in the zone". Consider sending a survey to the team a month after the initiative is standard, asking them "are you glad we did this". Survey results about developer moral are fair game to provide to management - "80% of our team loves the new auto merger, 15% like it, and 5% don’t care" - Success metrics also show management that the project indeed did work, which builds your credibility to do bigger projects in the future.
• Have an exit strategy - If you do one small initiative a month, it cumulates and you don't scale. Either make that tool/code/process absolutely maintenance free, or coordinate with management to hand it off to someone else.

Appendix

These are miscellaneous topics related to changing an IT department. If I were a star writer, I'd probably have found a way to integrate them seamlessly into the main article. However, it's easiest to just list them here.

What if you're not empowered to make the change?

Sujit spent 5 years developing .Net applications, and his boss has him pigeon-holed as an application-developer. Sujit can't set up build servers, purchase tools, bring in consultants, change the architecture, or do anything that would really turn his department's mess around.

There's still hope. Sujit can always at least defend his own turf and make "Individual Changes" (described above in "Three categories of changes"). For example, he could write his own private tool or script or code block to make it easier for him personally to comply with the broken infrastructure.

He can also support those who are empowered to make the change. Say the star architect, Mary, would love to push good initiatives, but just lacks the bandwidth. Sujit can assist Mary - he can build prototypes for her, do research, or even just provide moral support that all Mary's efforts aren't for naught.

I'm working 70 hrs a week on a death march, and I just don't have time to change

Sometimes you are in a "just survive" phase. People who have never gone through this misery tend to come off as naive and clueless, and don't get why others haven't already made the department perfect. Do what you can, with what you have, where you are.

Perhaps also use this as the reason you need change. Why don't you have time? Is it because the company is fundamentally screwing something - such as they don't do requirements or functional specs so the devs scramble 2 weeks before go-live to massively "correct" the application? You can tell your manager that you realize you need to solve the current crisis first, but this bad process has to be fixed, or you'll constantly be playing catch-up.

How do you know if your initiative is screwed?

First make sure that this is truly "screwed" and not just "inconvenienced" - initial rejection, compromise, busyness, and delays are not "screwed".

Given that, we've all learned the hard way that life isn't fair. Sometimes your department got painted into a corner - say the business (or industry) is fundamentally not profitable. Sometimes the team is just mentally entrenched and refuses to improve things. Other times the key players have "hidden agendas" and it's too much of a political game. However, I think in general the #1 cause of screwing the ability to make positive change is having bad management.

Good managers can internally start repairing the rotting infrastructure, bad managers leave you drifting in the wind. Think of:

• The manager who is so focused on impressing the VP with business features such that they fundamentally don't value the development infrastructure. If you want to keep giving the VP the golden eggs, you need to take care of the golden goose who lays them.
• The manager who won't acknowledge critical process failures even when they do occur. If you spend days to manually juggle 1000 files to deploy, and the deployment keeps failing, and management thinks that "that's just the way software companies are" and hence won't allow you to fix it, then you are screwed.
• The manager thinks that everything is an emergency, and thus constantly yanks you away from any long-term improvement to always put out short-term fires. They'll tell you to pump water till your lungs explode, but they won't let you plug the hole in the boat.
• The manager who just doesn't get it - they know neither the technology nor the business nor the management skills.
• The micromanager who controls every member such that they aren't free to innovate. If your manager controls which tools you can use to do the job on your private workstation ("do it how I did it 10 year ago"), or has developers controlled down to 30-minute tasks, you're probably screwed.

Ultimately, if you are indeed truly screwed and cannot possibly change the department, that’s a topic for another article.

Change: Incrementally Making Things Better (Part 5)

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/change_incrementally_making_things_better_part_5.htm]

Part 1 (Intro)

Part 2

Part 3

Part 4

Part 5

Part 6

 

STEP: Implement it in small, practical stepsAt a certain point, you just need to jump into the arena and get your hands messy. After all the meetings, word docs, PowerPoint slides, business ROIs, and cheering sessions, eventually someone needs to actually start writing code or changing scripts or procuring a tool so that the change actually happens. PowerPoint decks are not change; working C# code running on other people's machines is.Be practical - you must meet people where they're at. You want to give a drowning man a life preserver, not swimming instructions.

• Be prepared to build the prototype yourself - You may not be able to wait for your manager to give you schedule time or for the PMO to hire contractors to build it - necessity may demand that you start something yourself (this probably means nights or weekends). If the team thinks it has potential, you have a good chance of handing it off to other developers and letting them run with it.
• Your deliverable must be something concrete - Tools, approval emails from management, scripts, or code blocks are all concrete. An email with a link to a "cool" article, or a suggestion of what we "should do if we only had time", is not concrete - it will no more feed your team's need for improvement than an article on restaurants will feed a hungry family.
• Make it work - If you're making a tool, make it easily available (say, publish a working version to a public share - don't require them to compile the source code themselves), make it run on their machine, and ideally give it default config values so that it does something useful right off the bat. From the time Kurt agrees to look at your tool and you arrive at his desk, you have minutes to download it onto his machine, click a single icon or dos command, and have him see the pain that the tool saves him from.
• Start small, and continually add value in incremental steps - Have some deliverable every week. If you're working 20 hours on a project, there's got to be something to show for it. Avoid the "just give me 3 months and I'll give you the perfect solution," because they'll never give you a blank check for 3 months. Even if they do (say you've built up a great reputation with previous successes, so management risks big schedule time on your ideas), some big emergency will interrupt you 2 weeks in. You'll be constantly distracted with the "urgent" so you'll never get to actually do the "important". You're 3-month salvation project will lay in mothballs, taking some of your credibility with it.
• Don't be paralyzed by perfection. I.e., "perfect is the enemy of done". An imperfect solution that actually does something is adding more value (and relieving more pain) than the perfect solution that never got built. Consider building a quick "band-aid" or "throw-away" solution now to stop the bleeding and then building that perfect solution in 6 months when the schedule magically opens up and you have all the time in the world (yes, this is sarcasm).
• Don't be paralyzed by "coolness". Lots of developers like "cool" new technologies. However, such technologies often have risk and learning curves - which may mean that you only have enough time to come up-to-speed with the tech, but not to actually build something useful with it. Many of the infrastructure problems that most shops face have already been solved with older technology - look at classic books written in the 1990's like Code Complete and The Pragmatic Programmers, and ask yourself - how many of those good practices is a suffering department still lacking? Nightly builds, automated deployment, unit tests, modular design, layers - they were all done with over 10-year old technologies. If some cool new technology saves your day - great - but don't limit yourself to it. Sometimes a good old fashioned xml file and console app plumbing is sufficient to save your infrastructure.

Keep in mind that you must do all of this while still getting your Boss's priorities done. You cannot just "go rogue" and abandon your official responsibilities to do a bunch of research and innovation.

NEXT:  Part 6