<?xml version="1.0" encoding="UTF-8"?>
<articles type="array">
  <article>
    <allow-comments type="boolean">false</allow-comments>
    <category-id type="integer">3</category-id>
    <content>Its been a while since I have written a blog post here, really there's no excuse besides the fact i've just been busy with other projects! Today I want to talk about resignations, and how to handle a team member leaving. 

Generally you'll have an idea that a member is looking for work, or at least on the market. They'll take a few extra phone calls, they act distracted, and secretive. 

So the time comes, and it will come when this member will leave. But the way you deal with it, will determine how quickly the team can overcome this distraction and move forward, getting on with business. 

First thing is first, whatever the resignation letter says, don't believe it. Generally speaking the resignation will be short and sweet. The shorter the resignation letter the more problems this ex team member has. 

Take the time to talk to the team member, and try to understand what has driven their decision to quit. You'll generally find this will be a number of reasons, which usually stem from either money or a communication breakdown with the team or management. 

If its the later, theres a good chance that this team member would be talking to other members about the problems they were facing. 

Generally I've found, its best to let the person go straight away, generally they'll stick around and drive the team's velocity down. Morale will also fall, and it'll be great to move past this as fast as possible. 

Talking to the team about the recent events, and create a plan together about how you will all move past it. Its important to have the team come up with the solution, while you act as a guide only. This will empower the team, and bring them closer together.

If need be, talk to each member about what they're trying to achieve in life, and reiterate how your company will enable them to grow. What is important here is to let the team member talk. Spend a lot of time listening, and guiding the conversation into the positive. 

The team might be rattled if it was a shock resignation, but it rarely is. Just pay attention to your team. Spend the time to listen to the team, and plan ahead as soon as possible to recover quickly from a resignation. </content>
    <created-at type="datetime">2009-11-16T19:54:19+10:00</created-at>
    <id type="integer">9</id>
    <title>Handling resignations in your team</title>
    <updated-at type="datetime">2009-11-16T19:54:19+10:00</updated-at>
    <user-id type="integer">1</user-id>
  </article>
  <article>
    <allow-comments type="boolean">false</allow-comments>
    <category-id type="integer">2</category-id>
    <content>It seems as if the business doesn't understand anything about software development. They believe the best thing to do is shut the door and six months later they'll open it and get exactly what they want. And we as technical staff understand that software is a complex beast that must be thought about, planned, architected, documented and implemented, while throughout the whole process there should be due-diligence, testing, peer review, etc.

So trying to explain this to the suits led to one of them getting very upset and blurting out, "Don't write anymore tests, if you can't write bug free code, then we'll fire you and hire more professional developers who can write bug free code". At this point i boiled with anger, but bit my tongue and let him look like an idiot. 

So what can we do to show people like this, that being a professional developer means we write tests. Well it really depends on the person, some just don't want to understand, its easier to yell and scream and be on their way. 

But for others, especially those that are money orientated, or can see the bigger long term picture, than what i've found explaining the cost of a single line of code, quantifying it, helping them understand that without testing, without planning that line of code could get changed three to four times. 

Thats a lot of time to be rewriting existing functionality. So it can take three to four times as long to create / leverage the existing functionality for new improvements. Thats a lot of dollars when you think the average tests, planned line of code cost around $2-3 while untested, undocumented, unplanned  is reaching towards the $5 - $7 mark. Ouch, thats a lot of wasted time, energy, and money.

If they still don't listen, chances are the project will die. I would jump from the sinking ship, into something a little more stable.
</content>
    <created-at type="datetime">2009-06-01T08:03:45+10:00</created-at>
    <id type="integer">8</id>
    <title>Write bug free code or we'll hire more professional developers</title>
    <updated-at type="datetime">2009-06-01T08:13:23+10:00</updated-at>
    <user-id type="integer">1</user-id>
  </article>
  <article>
    <allow-comments type="boolean">false</allow-comments>
    <category-id type="integer">3</category-id>
    <content>I have to ask the question that rarely gets dignified by an answer. Why are we here? Now I don't mean why we're alive and on earth living day to day (although if you have the answer, by all means share it), but instead I'm wondering why I'm working for. What good am I doing? Could I do anything different to help improve the company I work for? All of these questions generally go unanswered by the powers to be. 

So the owners, executive team and of course the managers spend so long focusing on the customer, the market and the bottom line that they tend to forget that all of these things don't make a great business. What makes a great business is the people. I hear often from the execs and managers "I can never find good people", my immediate response is, what makes a person great? I've had a mixed response of answers, which when thought about all seem to be the same. "I want employees that work hard, are motivated and don't complain", they say usual with a laugh. 

I think everyone has the ability to be a hard working, dedicated and thoughtful employee if only given the chance. So the question is, how can we give them the chance? First of all a mission statement, and a vision for the company needs to be well thought out and written up on the wall for everyone to see every day. Once a goal has been written out you'll be surprised how dedicated even the least motivated staff can be. 

Also, you need a way to improve morale. This I believe is best done with a documented set of values and culture. Let the team understand what type of people need to be working for you. Do you want a highly corporate environment like IBM or would you prefer a laid back place of work like Google? Both get things done, but you'll attract completely different people to each organization. 

Make people feel wanted. Offer them excellent support, and let them know your happy with how they work. This doesn't have to be by remuneration 
but can be as simple as a pat on the back, and the acknowledgment that you see the good work they are doing. Don't be afraid to do something good for the body and soul as well. Biscuits, team, coffee, discounted gym memberships, lunch time walks, free fruit are a few suggestions, the sky is the limit, just remember a happy healthy body translates into a happy mind and soul. </content>
    <created-at type="datetime">2008-11-20T22:29:36+10:00</created-at>
    <id type="integer">7</id>
    <title>What Am I Doing Here?</title>
    <updated-at type="datetime">2008-11-20T22:29:36+10:00</updated-at>
    <user-id type="integer">1</user-id>
  </article>
  <article>
    <allow-comments type="boolean">false</allow-comments>
    <category-id type="integer">3</category-id>
    <content>Like always I'll ask a question to get things started, what role does your architect play in the success in your company? Where I work at the moment sees the architect's role simply creating some target state architecture documents. Generally in powerpoint presentations.. On further investigation of his target state presentations it seems they were borrowed from flickr and you tube.&lt;br /&gt;

In my time I think I've met one architect that was a documentation machine, others along the way tend to produce very little in the way of artifacts and instead spend their time producing pretty power point presentations or "researching". In my opinion, instead of sitting above the developers I believe these guys should be one of them.. &lt;br /&gt;

They should be involved in the code in a very intimate way. Maybe spending as much as 40% of their time with wrist deep building functionality. 20% of their time should be messing around with emerging technologies and the rest of their time should be researching and documenting findings.. All of these documents that are developer should be freely distributed to the development team and any one else who is interested. &lt;br /&gt;

To many architects tend to hord the information. How are the developers ever going to learn if nobody teaches them? You know you've found a good company when the developers are allowed time to research emerging technologies along side of the architects. So back to the original question, what role does your achitect play in the success in your company?&lt;br /&gt;</content>
    <created-at type="datetime">2008-05-15T21:16:54+10:00</created-at>
    <id type="integer">6</id>
    <title>The Architect</title>
    <updated-at type="datetime">2008-07-08T17:30:26+10:00</updated-at>
    <user-id type="integer">1</user-id>
  </article>
</articles>
