How to convince your boss

Written by dsg on December 13, 2011 Categories: business, relationships, work environment

When you need to convince your boss about something, such as upgrading your development machine, the most common mistake you can make is to talk about your problem. You’ll face some situations in which your opinion, your problem, your pain is not really that important compared to all the other issues your boss must deal with. In fact you should never make the assumption that the person you will talk with is going to put your interests before his own. Of course you know many people that will be genuinely interested in your well being, but most of the time, convincing someone to do something you think is good can be very difficult, especially for the introverts. Coming up with a solution instead of the problem alone is not enough. You must learn to focus on other people’s interests and come armed with facts rather than opinions.

Focus on him, not yourself

Focus your argument on your boss’s interests, and avoid mentioning yours. Let’s take the example of the machine upgrade: you want a new machine because your existing one is too slow and you really dislike working on it. Don’t go to your boss and tell him: “I need to upgrade my machine because mine is too slow, it is painful to develop on it”.  If your boss cares less about your comfort than his budget, you will certainly get answers like “Maybe later” or “I’m out of budget” or even “But you are not blocked right?”. Instead, put yourself in his shoes and try to identify what’s important for him.

To help you with that, try to ask yourself is how is he evaluated by his own bosses (or customers). How does he report his own performance? In that particular scenario, there are good chances that he will be praised if his team brings new functionality on time and blamed in the case of late deliveries. Your lack of productivity is the pain. Try to tell him: “I need to upgrade my machine because my productivity is really badly affected right now”. Be prepared to get another kind of answer! At best a formal acceptance without resistance but in many cases, a demand for clarification.

Come with facts

Any serious boss will ask for more information to understand your needs and eventually use it to validate their decision. You will certainly meet bosses that use them to cover their own backsides. Don’t wait to be asked for it, and augment your request with facts that demonstrate the real positive impact on the pain you identified earlier. Be sure to use real facts: articles written by an industry authority is not enough. There are good chances that your boss practices critical thinking and coming with blog posts from people he has never heard of will have little effect. For the example we used earlier you could calculate the startup time or the gain in compilation time. You must convert that time into a metric he is sensitive to: money. Multiply the time you save for one or two years by your hourly cost and compare it to your upgrade’s costs. If the gain is real, you won’t have any problem in getting your upgrade.

To increase your chances, be sure that your argument uses simple words to avoid any misunderstanding, especially if you are presenting it to non technical people. Be sure to be concise as well: you would be surprised by the number of people reading only the introduction and conclusion or who ignore any email longer than a certain size.

Formula = Boss Pain(s) * (Real) Facts * Simplicity * Conciseness

More tips

  • You should never ask your boss for permission to use a given development practice. Your boss should not impose a way to work on you but should focus on the result instead. You don’t tell the taxi driver how to drive his car. You don’t tell the hairdresser how to cut your hair. You don’t tell a coder how to work with his code. If you think your code needs refactoring. Refactor it. You are the expert, your team should decide what practices you use. Your boss is supposed to decide WHAT to do and more importantly WHY you are doing it. You should take care of  HOW you build it. If you are in the situation where your boss tells you how to work, you should ask yourself if that environment is really good for you.
  • If you want to attend a conference, try to compare the costs to formal training courses and be sure to put all the advantages such as the opportunity to network.
  • If you need a specific tool, be sure to scan the seller’s website to help you find the facts to make a good case.

 

 

No Comments

Related Posts

Why aren’t developers paid for the value they actually provide?

Written by dsg on November 25, 2011 Categories: management, salary

There are two main reasons. One is linked to the position in the hierarchy and the second one to the very common personality of programmers. You can’t change the former, however, you have more control than you think on the latter.

Most developers are positioned at the very bottom of the pyramid. This is fine: usually, nobody expects anything from you other than writing lines of code.  But many developers are providing much more value than the person just ahead of them, while generally having no possibility to earn more and be paid what they worth. The reason is that in our societies, we still think the salary is bound to the position in the hierarchy.  The analysts or project managers are higher in the hierarchy, so they should be paid more according to the rule.  The problem is easy to spot: position in the hierarchy in many cases is not directly related to the value you provide.

But why do many developers accept to be paid less than they worth? Developers and engineers in general tend to be introverted people. Introverts are often abused by extroverts. Some are aware of their value, but feel they have no control over their destiny, while others have been told since childhood that they worth less than others.  The former are convinced there is nothing they can do and the latter don’t know there is something to do at all. This leads to stagnation. Many extroverts are intuitively aware of that and use it heavily in their interactions with introverts. You need to take advantage of your introvert personality to survive in this world of extrovert people.

As a developer you are responsible for your current situation. If you are really paid less than you worth on the market, you need act on it.

Finally, I want to illustrate how this perverted system can sometimes work against itself.  Salary grades, for instance, can be very effective in many ways, but when poorly used and/or in strongly homogeneous companies (companies with lot of different skills involved), they can lead to very difficult situations for the employer. Below is the true story of one of my best friends.

My friend started as a programmer in a big hospital. Thanks to his hard work and dedication, he quickly became Oracle DBA, which was a critical position in a company where data is both sensitive and valuable.

The hospital worked with grades. Grades are bound to your position in the hierarchy, length of employment and diplomas. Salary increases were automatic and fixed in advance. In fact, he knew how much he would earn at every step of his career.

My friend got an offer to become DBA in another company that didn’t use salary grades. By accepting the offer, his salary could be increased a lot. Because he liked and respected the hospital he worked for, he decided to talk to the boss, asking for an increase. He just asked for what he was worth on the market.

The boss refused. It was impossible because of the grades and the unions would not let that happen.

My friend left.

The hospital eventually hired an external consultant (not bound to grades) and launched the recruitment process. The consultant did not know anything about the infrastructure in place, so his learning curve was huge. The hospital lost lots of money  training him.

The hospital carried on losing.  They could not fine a qualified employee to replace my friend and are still using the external consultant at 5 times what my friend asked for.

That was almost three years ago. My friend is still at his new place and climbing the hierarchy ladder very fast doing what he loves.

The hospital is still paying 5 times more.

 

No Comments

Related Posts

How to determine your current market value

Written by dsg on November 16, 2011 Categories: freelancing, salary

What you are worth as a developer is what the target market agrees to pay to have you on board.

What the market will pay fluctuates quickly, just like the financial markets, and can’t really be generalized, so websites with indicators can’t help further than giving you an indication. It may not be in sync with the value you can potentially provide because what the market agrees to pay you is generally subjective.

Knowing what you are worth on the market is an important bit of information you can get using the two proposed techniques below. One for freelancers and another one for employees and other permanent roles.

As a freelance developer, I was always asked by head hunters what was my current daily rate. At the beginning, I used to give a random number based on assumptions in the hope it would be accepted. I quickly noticed that it was always accepted… I deduced I was under market rate. I started to increase my daily rate by 50€ increments for each mission I was offered until I faced some resistance. Resistance is not a formal rebuttal by the head hunter but some sort indication that they want to negotiate. In order to prevent myself being abused by wheeler dealers type of agents, I always stayed firm on my position refusing any reduction. The accepted daily rate was my current market value.

For permanent roles and employees, you can’t negotiate your salary upfront without doing actual interviews. Here is the process I actually used to fine tune my method and that works very well for employees:

  • Update your resume & post it on the two main job advertising sites in your location or profession. You don’t have to be concerned about the fact that your actual boss may find it. In most cases, it will reinforce your position. The hiring process is a painful and onerous process. If he asks you why you do it, tell him the truth.
  • Try to get at least 5 interviews and find out information on the proposed compensation package. Be sure to include everything: salary should not be your main focus.  Location of the company, nature of the project, work environment, alignment with your career objectives are also things you should consider.
  • Take an average of at least 3 offers that you get, that’s your current market value.
This last technique can be used by freelancers to adjust their estimation of market value. I often noticed that the market value you calculate using the first technique is always a little bit lower that your real market value. This is due to the fact that your market value for a first 3 months contract as a freelancer is lower than what you are worth at renewal date.   The hiring process for freelancer is also very painful and pricey, so it’s often very easy for a freelancer to negotiate a daily rate increase with the agent at that time.   The agent has no extra effort to do to get an additional 3 months commission, so they won’t risk having no commission at all by refusing to increasyour daily rate a little.
Please note that this is true when the market is good.  When the market is bad, they have more choice and therefore they can replace you easily with someone else.  Knowing when you can negotiate or not is a skill you will get with time.
No Comments

Related Posts

7 telecommuting tips for developers

Written by dsg on November 7, 2011 Categories: productivity, work environment

Working from home or a private office is probably the future of knowledge age companies. It allows you to do away with commuting completely and to work in a quiet  and non (over) interrupted environment (if you decide to).  It’s the opposite of the open space office. The gain in productivity can be huge.  Both you and your (smart) boss are potential winners in the deal, not to mention the potential real estate saving for the latter.

Unfortunately, telecommuting is not for everyone though and this may be why it is not generalized yet despite the positive conclusions of the studies on the subject.  Procrastinators may find it very difficult stay as productive as they are at the office. You will also need lot of independence and self confidence.  Some employees may also suffer from isolation.

Procrastination and isolation are the two problems I will address in this post. Other problems related to telecommuting won’t be debated here such as:

  • security concerns,
  • the fact that telecommuters are less likely to be promoted (Kreitner & Kinicki, 2009),
  • potential loss of thrust by managers
  • communication problems with your team

Here are the 7 things I strongly suggest you to try.  I have experimented with this myself during the past 10 years. They provide some tips to help avoid both procrastination and isolation. Disclaimer: you may adapt them to your particular case and not take those empirical & personal observations as a generalization of what to do. I really encourage you to share your own experiences on the subject in the comments.

Procrastination

1. Use a schedule – as if you were in a formal office.

If you don’t do so, you will be tempted to work too much or too little, depending on your personality. Both are problematic long term. Having a fixed schedule will not only create some sort of rule to manage your time, but also help you beat procrastination.

One of the keys to beat procrastination is to have “starters” and avoid “retarders”.  If you like to do non work related stuff such as reading news or browse internet, reserve 30 minutes before and after your fixed work time for it.  When you feel the need to do it while you are into your work time, remember you will be able to do it after.  It usually calms down the need for it and after some some time, the addiction will disapear.  When you arrive at your work time schedule, close everything and start working. This can be hard the  first few (ten) times, then after a while the habit will kick in.

In order to avoid the frustration of having to leave off work in a middle of something, I try not to start debugging or another task that has unpredictable time duration at the end of the afternoon.

2. Replace commuting by physical excercises and meditation/relaxation.

Telecommuting will free up a lot of time, and you should take it as an opportunity to take care of yourself, and certainly not work more for the same salary. Consider physical excercies and relaxation or meditation. It will improve your overall productivity and will contribute to reducing procrastination (Davis & Jones, 2007).

3. Take regular breaks

Since you don’t have your environment anymore to remind you it’s time to take a pause, use the pomodoro technique. I personnaly taking a break of 10 minutes every 45 minutes, but you may setup your own schedule. I use a special software for that called Workrave that I warmly recommend to you.

The pause can be either doing nothing (it’s what I do every other break) and free your mind or do stuff off your computer such as class papers or call a colleague.  In any case, this should occur in another room, and certainly not in front of a computer.  I personally do three minutes of mindfulness or simple observation of what is happening outside (simply being in the present moment).  Feel free to adapt this to what works best for you.

At noon, take a full break and don’t eat in front of your computer.  Some of you may enjoy some cooking time while others may be very relaxed by some time listening to music.

4. Put clear limits between work and your normal life.

This means you have a dedicated office/room you don’t use for your pleasure but only work.  This is very important especially if you have kids.  Your office should not be used to anything else than working. This also means:

  • don’t work on your laptop when you are watching a movie with your family
  • avoid any professional activities during the weekend
  • remove all work thinking and be 100% mentally available for your well beloved
Isolation

5. Go to lunch outside.

Isolation is the other major inconvenience to combat if you are affected by it. To avoid isolation a great solution is to integrate a social lunch with others. Try to do this at least once a week.  Even if not with someone else, try to go outside at noon somewhere there are other people.  Why not with other telecommuters?

6. Do co-working.

Co-working is the new trend that involves a shared working environment for people even if they have independant activity. It feels like your office, but it’s not. To make this work, the co-work area must be close to your home.

7. Don’t telecommute every work day.

If you telecommute every work day, you will progressively become more and more disconnected from your company’s culture and people.  It’s inveritable and it will happen.  Be sure to dedicate one or two days on site.  When on site, go to lunch with your colleagues.

 

No Comments

Related Posts

I love software development, but I hate doing it for a boss

Written by dsg on November 1, 2011 Categories: entrepreneurship, freelancing, relationships

Unless your boss is really a bad guy, you should reconsider the feeling. If it’s just that you don’t want to work for someone, don’t work at all. Because when you have your business you work for a boss much worse than your existing one: yourself. You will eventually work for many other bosses that really don’t care much about your feelings: your customers.

If you really love software development, if it’s what you are made for in life, creating your own company may be very disappointing. Today you do what you love (developing software) for most of your time. When you are an entrepreneur, you handle many other unpleasant tasks. You have no choice but to increase your work hours to be able to produce valuable lines of code. You will have to do lot of administrative tasks, handle customers (requests, complaints, questions, …), learn legal & accounting stuff, call people, sell your stuff, handle employees (requests, complaints, questions, …), think about tons of things at the same time … all of this increasing your overall anxiety and fatigue.

Here is a quick test to see if you, as a developer, are likely to succeed as an entrepreneur. Answer each question by true or false.

1. I dislike the sales part of the process and prefer to make the product

2. I’m a perfectionist

3. I won’t accept to be paid less than my market value for an extended period of time

4. I really like to take care of the details

5. I really dislike being criticized by other people

6. I don’t have any savings or personal investments

7. I have never been fired

8. I don’t have friends or family that run their own businesses

9. I am afraid of losing all my assets

10. I’m an anxious person

If you answered “True” at least three times you should seriously reconsider creating your company.

If you really want to start your own business, consider creating a consultancy company first, then create your products later. Many successful software companies started like this. It works because the services (much more easy to get money from) pay the bills while you develop your products. If the product fails, it is no big deal.

No Comments

Related Posts

WHO broke the build?

Written by dsg on October 11, 2011 Categories: agility, relationships

Breaking the build is highly prejudicial to the productivity of a development team. Since it’s pretty easy to avoid it by ensuring that the code compiles locally against the latest version and doing continuous integration, it is often taken as an act of rudeness.  The person responsible for the act must therefore be punished.


Photo courtesy of seeb’s Photo Stream

The punishment often consists of making the guilty party wear a specific hat (we use a Sombrero) or any other very visible humiliating clothes, until they solve the problem themself.  In addition to this, some teams may want to signal breaking builds with a specific sound played on speaker (we used a darth vader or homer simpson voice).  Some teams get even more creative as you can see in this video.

I found the whole thing very funny and I always promoted it in every team I worked in to reinforce team spirit.  That is until I met a couple of people who were really reluctant to join in and did not want to publicise their actions.  Even when I broke the build on purpose to wear the hat, it did not change how they felt about it.  One of them was from a different country where such humiliation could not be taken to this degree (as we can, I hope).

I think this kind of game is one of the many things we see online and we want to replicate without thinking, but it is not always a good idea. While it can be a very good team building feature, it can also contribute to making some team members very uncomfortable.

If you really want to do it as the manager/team leader, ask every one in the team individually. Asking in front of others will prevent you from getting honest feedback.  In fact, it’s usually better not to implement such a rule in your team unless it’s really something everybody wants.

 

 

 

1 Comment

Related Posts

How to successfully enter a new company or domain

Written by dsg on September 1, 2011 Categories: freelancing

As a consultant, I worked in various domains such as utility, telecom, aeronautics, finances, insurance, etc and I’ve faced the problem of not knowing very much about the domain I was entering.  With time, I discovered a very simple method that works: being actively curious.

  • Request a one to one introductory meeting with your supervisor with the purpose of getting them to explain the business domain (the big picture). It should not last more than 4 hours (or you will get bored and your supervisor exhausted).  Prepare your questions in advance.  Take notes.
  • Ask the supervisor for a field visit. When I worked in the telecom industry, I asked to visit the router and transmission rooms as well as the NOC (Network Operations Center). It helped the team building the software to understand the purpose instead of blindly writing code. We knew why our stuff was useful and more importantly, who will be using it, and how.
  • Have frequent lunches with suits.  More frequently, I would say, than with fellow programmers. They love to talk about their stuff and if you listen carefully, you will learn lot of amazing things.  Be prepared to share some amazing stuff with them too or they will soon find you very boring.
  • When you have the occasion, visit the departments. Ex: when I had to work with a marketing manager of a big finance institution, I asked how our applications helped them and what was her routine.  By actively listening to her, I was able to find out new stuff to automate and make her work life easier. I suggest you make a physical visit rather than a phone call.  This means you can see her doing the thing and more importantly, using your application!  What is obvious for you may not be so obvious to the rest of the world.
  • Buy books on the domain and watch youtube videos. Read your domain’s information websites as well. Give priority to higher level literature. Books that are too technical could be boring or impossible to understand in the beginning. What you need is general concepts to fuel conversations and learn more.
  • Talk about it to your friends & family often. Talking about your stuff will help you integrate the huge amount of information you must learn. Prepare an elevator pitch and be prepared to give details. Don’t hesitate to write it down so it is easy to remember.
  • Read all the news your company publishes. Including yearly reports. In fact, the first thing to do when you are hired by a new company, is consult their website and publications.
  • When you don’t understand something, don’t hesitate to ask the guy in the company (email preferred) that can answer your question. The worse thing that could happen is being told that (s)he has no time for that.

Remember this: the developer that knows the domain very well is no longer just a simple developer.  You are a little more than that.  And so is your market value.

No Comments

Related Posts

The Agile Essentials Checklist

Written by dsg on June 18, 2011 Categories: agility, checklist

Here a “light” Agile Software Development checklist that I have used for many years to introduce Agile in organization. I usually introduce few items per week.

Product Management

  • A product Backlog, estimated and prioritized by a “Product Owner” is used
  • A “Release Plan” exists and is known by the team
  • A “Company Strategy” exists and is known by the team
  • Features are divided into “User Stories”
  • The “User Stories” are estimated by the whole team using “Planning Poker”

Workflow

  • The development work is divided into iterations or timeboxed “Sprints” or “Iterations”
  • A “kanban” or “Information Radiator” is used
  • The tasks are not assigned, the team organizes itself
  • The “Velocity” of the team is known
  • No outsider can interfere directly with the team during an iteration
  • “Daily Meetings” take place and do not last more than 10 minutes
  • A “Sprint Review” is organized and the output recorded
  • A demonstration is held at the end of each iteration
  • The problems are tracked and by the “Scrum Master” and/or management
  • A “Burndown” graph is updated daily
  • The “Code Reviews” are systematically organized

Development Tools & Rules

  • A source controller is in place
  • A continuous integration build server is used and testing (unit & guidelines) takes place at each commit
  • The packaging of the product is fully automated
  • A (simple) bug management tool is used
  • Each bug is reproduced in a single test and then corrected
  • 80% of the code is covered by automated testing
  • A “Solution Log” in WIKI form is used
  • The “Coding Guidelines” are defined and understood by all
  • A maximum of 40 work hours per week!

Please note that any numbers above can be adjusted to your reality.

 

No Comments

Related Posts