Saturday, December 31, 2011

The five types of power

“Nearly all men can stand adversity, but if you want to test a man’s character, give him power” Abraham Lincoln (1809-1865) Politician. President of the United States.

What is “power” as a manager?  What powers do you have in the workplace and how should you use them?

In a classic study social psychologists John R. P. French and Bertram Raven developed a schema for sources of power and suggested there are five significant categories from which power derives:

  1. Legitimate – This is the power of an individual due to their position and duties within the organization.  Legitimate power refers to formal authority such as a boss and his subordinates.
  2. Personal/Referent – This power refers to the interpersonal skills of an individual and their ability to attract others and build loyalty. 
  3. Expert – Expert power derives from a person’s skills and knowledge.  In product development this refers largely to technical skills, but it also refers to expertise in other areas such as methodologies and patterns. 
  4. Reward – Reward power refers to the ability to give others gifts such as raises, promotions, time off, etc.  Rewards can come in all shapes and sizes and even calling out someone’s hard work in a group meeting can be a powerful reward.
  5. Coercive – This refers to the ability to instill negative consequences such as withholding rewards or enforcing some punishment.  This is generally the most obvious and least effective form of power.
Now let’s do a little exercise... 

Take a moment and write down the percentage of each of these powers that you currently use in your management style.  When you have completed this, write down what you feel an ideal percentage distribution would look like. 

Are you where you want to be?   I’d be surprised if you are.  When I first did this test about a year ago I know I wasn’t.  To understand more on the effectiveness of these types of power, let’s talk about each in more detail:

Legitimate power is easy to understand, but should only represent a small portion of your power portfolio.  Hierarchies (organizational, social, etc) form the basis for legitimate power.  But the power really arises from the position, not the person.  Remove the position and the power is gone.  Legitimate power is limited to situations where you have the legitimate authority to control.   This is certainly useful in some situations, but if you give it some thought you’ll realize how many of your daily interactions do not involve this power.

Personal power is one of the most powerful types of power available to you.  This power comes from one person liking and respecting another.  People with this referent power generally make others feel good and others have an attraction toward them.  Much of this power relies on an ability to identify with the other person in some way.  In some cases in the workplace this will come very quickly and easily.  In some cases it can be very difficult.  Afterall your team is probably not all just like you are (nor should they be).   So you will not have strong referent power over everyone you lead.  I believe that Referent power as the most important power basis. If a person likes and trusts you, helping you becomes a reward in itself regardless of any express reward or legitimate power relationship.  If you look back at some of the greatest leaders in human history such as Jesus, Mohamed and Ghandi these leaders all used mostly Referent power

Expert power as title suggests exists when others believe a leader has “expert” knowledge and skills.   As you demonstrate expertise you build respect with your team and your ideas carry more value.  You can probably think of some people on your team that may have expert power that are not in a position of legitimate power.  In software development expert power carries more weight than in some other industries.  Software engineers are often very technical and respect a boss that has the technical chops to really engage in technical discussions.  Therefore in software development expert power should be a strong component of your power portfolio.  However as a manger you should not expect to be an expert in everything.  The best managers hire people that are better experts in the areas the manager is not.  Further, expert power is highly specific and limited to the particular area you possess expertise in.  In management there are many other areas you will need to show leadership besides technical decisions.

Reward power is based on the fact that others will do what you want if they feel they will be rewarded for it.  “Meet our goals and we’ll get a bonus” for example.  But there are many other rewards such as a half day off, donuts in the morning or a better cubicle.  This initially seems like it might be the strongest form of power, but there are some drawbacks.  Firstly the reward must appeal to the person receiving it and everyone has different preferences and needs.  Secondly in the workplace a manager often does not have all the authority to make reward decisions.  Raises, promotions, bonsuses, stock, etc. are often based on performance of the company as whole, require multiple approvals and are based on policies set by others.  This leaves many things out of a manager’s control.  Even a CEO has to answer to the board, shareholders and customers.  Finally, reward power can weaken and lose effectiveness if used too often.  That box of chocolates you bought may seem like a great gift one day, but if given frequently becomes boring.

Coercive power is the opposite of reward power.  The leader has an ability to enforce penalties such as verbal abuse, reduction of privileges or poor task assignment.  The leader must have the actual authority to implement the penalty and the penalty must be something the follower actually cares about.  Coercive power is the weakest form of power available to you and should be the least used, though there are situations where it is necessary.  This power can be easily abused and must be used carefully.  It can lead to unhappiness which can spread into an array of problems for the entire team.  Too much reliance on this form of power would be a very impoverished way of management. 

One important thing to consider is the cultural and personal differences in the respect and usefulness of types of power.  For example in cultures like India and China legitimate power carries a lot more weight than in the United States.  And team members on your team will respond differently to different motivations.  As a manger you must understand your team members and utilize different powers on an individual basis.

All the sources of power are useful and each should have its own place in your management style.  Give some thought to the sources of power you are currently utilizing and under-utilizing and how you might adjust these for different people and situations to make 2012 a more effective year of management.  


Tuesday, November 22, 2011

You Ain't Gonna Need It!

"Always implement things when you actually need them, never when you just foresee that you need them.", Ron Jeffries

One of the rules of extreme programming is “Never AddFunctionality Early”.  This concept is also often referred to as “You Aren’t Gonna Need It” or YAGNI.  The basic idea is to only add features when you need them, even if you are absolutely sure you will need it later on.  Yes you may very likely need the feature one day, but you never know what the future holds.  Building something you don’t need is obviously a waste of time and even when you do need it, by the time you get there it’s often different in some way than what you previously envisioned.  Following this principle keeps your system uncluttered, simple and meeting the requirements without extra work.  

Time and time again in software engineering the product owners and engineers suggest adding some “small” piece of functionality into the current release that is planned for a future release, or not planned at all.  It’s easy to be tempted to add something because it seems easy or seems like a good improvement to the product but this is almost always a bad idea.  To understand this I want to walk you through an example:

In our case we have already done some designs for future releases of the product and for this example we’ll keep it simple by referring to two releases: V1 and V2.  We have a field on the UI which is dependent on several attributes.  Some of these attributes are to be populated in V1 and others added in V2.  When it came time to build this UI field, the product owners made the suggestion that we add the attributes for V2 to the data model even though they will just be empty for V1.  Seems easy enough right?  Just add some fields to the data model that are always NULL and have the UI rules already in place.  According to the product owners this was even better in some respects because we’d have all the attributes defined that we’re going to need already and when we write this UI algorithm we only need to do it once and won’t have to change it in V2.  Let’s look at the many reasons this is wrong:

Time spent (however seemingly small) adding any unnecessary (at least for now) functionality is time taken away from adding necessary functionality

Generally speaking time spent moving toward a solution is more important than time put towards a fully complete solution.  At some point things need to be done, where “done” does not necessarily mean total completeness.   Don’t lose sight of the need for progress and shorter term milestones. This should be applied not only to the overall release, but also to iterations during the release.  For example if something is needed for the release, but not for the current sprint than you should not detract resources from achieving the current sprints goals.

Another important consideration here is that things aren’t always as simple as they appear.  Even adding some simple DB columns has impact on data access layer (entity objects, etc), data import tools, SQL queries, database performance, etc.  We’ve all had experiences where a “simple” feature turned into Pandora’s Box.

Time changes all

If you can predict the future you should probably be in a different job.  Until a feature is actually needed and committed to it is difficult to fully define what it should do.
Imagine V2 is scheduled for two years after V1.  Can you really be sure this design is sufficient for that time?  Are you sure of your customers and their needs in the future?  Even some database fields that seem so basic and immutable can easily change their meaning over time. The logical data model is always a moving target and it would be naive to think it won’t change again. 

Half supported functionality has no benefit to the customer

Putting in some work to get a head start on the next release is not for the customers gain.  It will only end up causing problems when they try to use this functionality or it gets in the way of something else.  

Code bloat

As unnecessary changes are added, the code base becomes larger and more complicated which is against our principle of simple design.  Keeping your code ready for unexpected changes is not about adding extra functionality or flexibility; it’s about a simple design.

Documentation

Even unused or partial features may require documentation.  In our example every field in the data model must be documented and that takes effort.  Also I don’t want to be the one explaining why a column might exist that is not really used.

Snowball effect

Adding one piece of functionality opens up the door to adding other pieces.  This results in the dreaded “feature creep”.  In my little example if I cave on adding these V2 attributes, it becomes hard to draw the line on including all V2 attributes into V1.

Extensibility

Now-a-days applications are being built to be very extensible by the customers.  If you’re adding something to be used by a very small (if at all) percentage of your customers, then perhaps its better accomplished as a custom extension by that customer in the first place rather than complicating your horizontal offering for everybody.  If you’re only partially meeting the requirements, then the customer is going to have to do work anyway to enable this functionality.  In that case the head start you gave your customer is probably not worth the time it took you to add it.

Refactoring

Would refactoring eliminate this functionality?  You should already be constantly refactoring your application to make it simpler and/or faster.  If you add something that would be flagged for removal according to your refactoring principles, then why add it all?  In this example some database columns that are never actually populated would certainly be flagged in one of my reviews.


To summarize, adding functionality you don’t really need is usually a bad idea.  Adding partial functionality is almost always a bad idea. As a development manager you need to focus on the current needs and constantly remind yourself what those needs really are.  Use common sense and be open to adding features that make sense and will be used immediately but remember that most of the time that new piece of functionality is not easy, is not better and is not faster to add now than later!

Monday, October 31, 2011

Sprinting with a log at your back

For all those using SCRUM out there here's my joke of the month:
Sprinting with a log at your back
















This is a  wonderful picture my team at Oracle drew of me earlier this year.  As a scrum master I was constantly obsessing over the backlog, though not running away from it!  If you are not familiar with SCRUM this will surely make no sense to you.  In that case its time to do some reading so you can learn this great development methodology and understand the joke :)  And look for more information on scrum in future postings on this blog.

Thanks to Amod Pandey, Mahesh Saka and Nikhil Baliga for drawing this; you guys had the skills and attitude that made working with you a pleasure.

Wednesday, October 12, 2011

Giving your employees a great start

“An employee can only be as good as their manager let’s them be” Billy Turchin

So you’ve found a great candidate; he’s accepted your offer and will be starting soon.  Now what?  How do you get your employee up to speed quickly, set proper expectations and re-enforce that he made an excellent decision by joining your team?  

As a new or even seasoned manager, it can be difficult to bring on a new employee and keep track of all the things needed to be done by you and the employee.  I recommend developing an orientation plan before they start which has the following sections:

  • First day
  • First week
  • First month
Within each of these we’ll be placing activities that fall into four basic categories of learning needed in the employees first few weeks:  Organizational, Technical, Functional and Managerial.  Let’s review each of these and the types of tasks they contain that your employee will need to do in their first month.  Then we’ll build a sample orientation plan.

Organizational

This refers to learning the policies and procedures of your company, as well as general office logistics.  You’ll probably get some help from your HR department on these, but much of it will still fall on you to make sure things are conveyed to the employee correctly. 

Activities included in this category:
  1. Touring the office
  2. Introductions
  3. Setting up computer and network accounts
  4. Phone, voicemail, etc.
  5. Learning company policies, going over employee handbook
  6. Setting up payroll (for example I-9 form), benefits, direct deposit, etc.
  7. Completing any mandatory company training
  8. Learning important websites and where to go for help
  9. Learning the reporting structure and org. chart

Technical

This refers to learning the technologies your team is using.  Perhaps you’ve hired someone that already knows all the tools and libraries, but often this is not the case.  This section of learning can be a combination of taught and self guided.  I’m often a fan of a “trial by fire” approach where I like to throw a new employee rather quickly into actual, small development tasks for a project.  This is not to discount the value of training, but there is no substitute for getting into the details.  In some cases employees don’t get the luxury of much training and this all depends on your situation.  But even if the employee is technically very savvy, they will not be familiar with how your company uses those technologies.  Some level of technical training is always necessary in the first few weeks, even if plan a trail-by-fire and this should not discounted.

Activities in this category include:
  1. Instructor led training classes
  2. Virtual training or previously recorded training sessions
  3. Reading online documentation
  4. Building prototypes
  5. Writing documentation on how a library or feature works
  6. Inspecting existing code and documentation
  7. Knowledge transfer sessions
  8. Mentor partnership with an existing employee
Functional

This refers to learning the domain of your software and the functional requirements of the projects they will be working on.  You will need to help your employee learn things like what your product does, who uses it, what the acronyms are and what environment your product is used in.  Depending on your project the learning curve can vary greatly.  If you are working on a complicated project you want to ease your new employee into it by first focusing on high level overviews and going into detail initially only on the area(s) this employee will be working on to start.

Functional training is generally the most overlooked aspect of training.  New engineers are often thrown into building something without understanding the bigger picture.  The cost of this is then felt later when they don’t produce fast enough, or they produce something incorrectly. 

Activities in this category include:
  1. Demos of existing products
  2. Whiteboard session with the manager on product function and design
  3. Reading functional design documents
  4. Meeting with product owners and customers
  5. Company overview documentation, glossary, etc.
  6. Reading technical design documents
  7. Inspecting the code
Managerial

This refers to educating your new employee on your managerial style and your expectations.  This ranges from logistics of how and when things are done to defining their role on the team and responsibilities.  This can be surprisingly overlooked.  A manager may not clearly set expectations with a new employee, expecting them to “fall into the groove” of the existing team.  As I’ll be writing about in a future posting, setting clear expectations of your employees is one of the most important things you can do as a manager.  Don’t let assumptions, conflicting priorities and misinformation cloud your employees judgment.

Activities in this category include:
  1. One on one meetings with the employee
  2. Checkpoint on progress after each week, month
Topics to review:
  1. Work hours
  2. Working from home
  3. Team meetings
  4. Development methodology
  5. One on one meeting schedule
  6. How they fit in with existing team
  7. Mentoring of or by other team members
  8. General role responsibilities
  9. How they will be phased into the project
  10. Career goals / personal development plan
  11. Objectives for the month/quarter/year/etc.
Writing the orientation plan

You’ll want your orientation plan to group the activities from the four learning categories into three time period buckets.  This builds a checklist of activities by time for their first month.  Some of these may extend beyond a month, but most of these things should be accomplished within the first month.  Having this checklist ensures you don’t miss anything and also gives your employee a clear view of their first month on the team. 

The first day should generally cover most of the organizational activities, but also some of the managerial review.  It’s important to set some expectations very clearly upfront with your employee.  For example, something as simple as what time to show up the next day is good to convey.  Then over the course of the first month you’ll expand on the managerial topics. 

The first week should be about completing the organizational activities and beginning technical and functional training. Most managerial items you did not cover on your first day should be covered within the first week.   Plan to have a one-on-one meeting with your new employee on the first day and one other time during this first week.  I would not expect much “real” work in the first week.  The reality is in most cases if you expect someone to “hit the ground running” you are not setting realistic expectations. 

The remaining weeks of the first month will be all about continued learning and starting to get actual project work done.  Finally at the end of the first month you’ll want to checkpoint on your employee’s progress in a one-on-one meeting.  Talk about the first month, what was learned and what is still missing.  For most software development jobs a month is not enough time to get totally up to speed on everything needed for the project, but at this point the employee should be well on the way to productivity. At this time also review your managerial checkpoints and make sure they are clear on your expectations of them going forward.

Another trick to a successful on-boarding is to make each new employee in their first month update the on-boarding documentation and orientation plan.  This way the material does not become stale and is updated based on what the new employee actually goes through.

I also recommend assigning someone else as a go to employee that can help get your new employee get up to speed.  This needs to be done in the first week.  Firstly this alleviates you from having to aid with all of the technical and functional training. Secondly this gives the employee someone else to turn to when you are not available.  And finally it allows the employee someone else to talk to if they have questions they may be embarrassed to ask you.

The first orientation plan is the hardest.  Once you’ve built an orientation plan for one employee, it can be used as a template for future employees.  People with different job roles and different experiences will have slightly different plans; however most of it will remain the same.  I recommend keeping the plan as a document which you print and give to your employee on day one.  Once you put this plan into place the stress on you for their first day and month can be largely alleviated.  It also eliminates a lot of stress on the new employee.

I recommend the first thing you do on the first day with your employee is to go over this plan.  Imagine if you had this on your first day and immediately had a clear understanding of your first month … now that’s a great start that will certainly inspire confidence in the manager!

Below is a sample non-specific orientation plan:

First Day
  1. Review orientation plan
  2. One-on-one meeting (review expectations, meetings, dress code, hours, org chart, etc.)
  3. Building – tour, badge, office supplies, phone, etc.
  4. HR paperwork
  5. Lunch!
  6. Team meeting, introductions
  7. Computer setup
  8. Important websites
  9. Requesting accounts and system access
  10. New hire wiki page / technical setup
First Week
  1. HR policies, employee handbook, etc.
  2. Mandatory training
  3. Product demo
  4. Start technical training – self guided and directed
  5. Read functional design docs
  6. Read technical design docs
  7. Assign a mentor
  8. Enroll in training classes if needed
  9. Finish computer setup and technical environment configuration
  10. One-one-one meeting (review management style, expectations, development methodology, meeting schedules, travel, ramp-up plan, objectives for first month, etc.)
First Month
  1. Continue technical training
  2. Continue functional training
  3. Writing or updating training documentation
  4. Update orientation plan and new hire docs
  5. Start on project tasks and/or prototypes
  6. One-on-one meeting (review career goals, personal development plan, objectives for month/quarter/year, training, expectations, debrief first month, etc.)


Tuesday, September 20, 2011

Do I really have the most hated job?

This month I wanted to share a surprising post from CNBC on the 10 most hated jobs (assuming in America):

http://finance.yahoo.com/career-work/article/113308/10-most-hated-jobs-cnbc

I actually find this almost funny ... why?  The number one most hated job is ... Director of Information Technology … and well, that is pretty much my job!  I believe my technical title is along the lines of Director of Application Development and Integration and while I'm more heavily involved in software development than a traditional IT Director, I really share those same responsibilities in addition to building software.  According to the article:

“…IT directors reported the highest level of dissatisfaction with their jobs, far surpassing that of any waitress, janitor or bellhop.”

Lucky me!  In all seriousness though, I don’t hate my job.  But it is stressful at times and requires real leadership and managerial skills.  And this is often lacking in IT organizations.  I think this article further backs up the need for this blog and education around management in information technology teams.  I believe that most of the problems experienced by these leaders of IT are fundamentally management problems. 

The quote this article chose to sum up the antipathy, “Nepotism, cronyism, disrespect for workers”, seems to be from a particularly disenfranchised Director that is very bitter about his or her situation.  This is a situation where the Director felt as though rewards were not distributed based on merit and they were not enabled or capable to institute effective change. Clearly at the root of it, this is a management problem. We’ve already begun to talk about some of these issues and in future postings I will get into further detail on how to prevent this from happening in your organization.