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.

Monday, September 5, 2011

Taking over an existing team

Many opportunities will arise in your management career to earn a supervisory role over an existing team.  You may get promoted, change companies, replace someone or just grow your team in a re-organization.  This is a tough time for a manager because the team is often largely unknown to you with their own processes, habits and team dynamics.  You must smoothly meld your way of doing business with theirs.  If you don’t take charge and demonstrate your leadership strength you won’t earn the respect of the team and provide value over they way they used to do things.  But if you institute change too quickly or incorrectly you’ll alienate your team, lose their respect and reduce their strength. If you are being promoted from an individual contributor you may have some understanding of the team already, but you now have to carefully manage your new supervisory responsibility.  The following tips will help you through the transition period and leave your team wondering how they ever managed without you.

Prepare

Firstly find out as much as you can about the team you are taking over.   You’ll need all the information you can gather ahead of time to diagnosis the current state of things and get an idea of what to expect.  Hopefully you can begin this process before the change in reporting structure takes place.  Speak to the teams existing manager and get his or her opinion on some key points:  

  • What are the strengths and weaknesses of the team as whole?
  • What are the team’s current goals and responsibilities?
  • What are each person’s strengths and weaknesses?
  • What would you identify as the top 3 areas for improvement?
Remember not to take the existing manager’s word as fact, but as a piece of the puzzle which you’ll assemble on your own.

If there are new areas of technical or functional expertise you are inheriting: STUDY!  Read up on the business domain, tools, etc.  This will allow you to build some knowledge depth so you can establish more credibility at the beginning.  You won’t become an expert overnight, but you can really impress the team by talking the talk.

Recognize that you will be judged

In your first days or weeks as the new boss you will be studied carefully.  People will notice what you wear, what you say and how you say it.  Project confidence and always adhere to your moral code of treating everyone fairly and honestly.

Communicate

Meet your employees immediately, even if you can’t have one-on-one meetings right away.  Be approachable and offer for them to come to with anything from the first day.   Even if the existing team is productive on their own and you have other priority issues to tend to, during the initial transition period it’s crucial that you are present and communicate with them.  Silence will just leave people to gossip and speculate. 

Introductory one-on-one meetings

This is the most important step in taking over an existing team:  Spending some private 1-1 time with each individual direct report (and often many indirects).   These meetings should happen as quickly as possible.  Even if you are not yet familiar enough with the project to have insightful opinions on strategy and goals, it’s still critical that the team members get an opportunity to begin establishing a personal relationship with you as the basis for building trust and credibility.  If some of your team members are remotely located this is still just as critical and someone needs to travel.  Employees will often be very anxious about a new manager and without face-time this is only amplified.

Here is a template I like to following to these initial meetings:
  1. Tell me about yourself.  Do you have any hobbies; what do you like to do for fun?
  2. How long have you been with the company and with this team?
  3. What things have you been working on recently?
  4. Tell me about your view on the teams goals?
  5. Tell me about your view on the teams challenges?
  6. Do you have any comments or suggestions on improvements to the team?
  7. Is there anything in particular you’d like to be working on?
  8. Let me tell you a little about my management style and philosophy.
  9. I’d like to schedule a recurring one-on-one meeting with you.
  10. Anything else you’d like to talk about?
Ask and listen

Whether you’re a new manager or a seasoned pro, you’ve got a lot to learn when taking over an existing team.  Don’t be afraid to admit it.  As a manager you need to show strength, but you’re still human and showing that to your employees will get you farther than attempting to show you know it all.  Ask your employees “What do you think?”  They’ve probably been in this team for a while have some well thought opinions.  You should genuinely listen to them. 

Start small

Don’t rush to place blame or change your initially perceived flaws of the team.  It’s often easy to blame the previous manager for any problems, or perhaps even to blame the team for driving out the previous manager.  When you enter a new team you will not have first-hand knowledge of past conditions that got the team to its current point and this information will not all come up easily at the beginning. Any team often has issues that were not easily exposed on the surface of things and would not come out in your introductory meetings.  The longer the history of the team, the more deep rooted issues based on the past could be present.  The point is that any team is a web of complex human interactions and when entering in from the outside you need to take a good amount of time to understand things before passing judgment and making quick fixes. Start small and earn your teams respect with some successful changes.

Set expectations

They say the biggest problem with communication is that too much is assumed.  When you take over an existing team you have your assumptions and they have theirs.  Make sure your team understands your initial expectation of them from the start.  You may be surprised that they don’t operate in a certain way that you are used to, or vice-versa.  If any conflict arises because something isn’t done in the manner you expect, the fault lies on you if you did not clearly set the expectation at the beginning. 

Re-establish focus

Sometimes existing teams lose sight of their real purpose, or they never had one.  They chug along doing their jobs without long term goals, or a solid foundation to base their decisions on.  This is akin to a manager operating without a management philosophy.  Once you’ve had sufficient time to acclimate you should re-establish the following:

  • Goals
  • Scope and boundaries with other teams
  • Roles and responsibilities
  • Meeting policies and schedules

Remember transitioning to a new boss is a traumatic experience for the team.  The team members will hunger for leadership and confidence.  Even if you are scared about the transition, you need to “grab the bull by the horns” and show them you are the leader they long for.


Tuesday, August 30, 2011

New headshot





Realizing that I didn't have a decent head shot and had been using a cropped picture from a group of friends at a wedding, I had my wife take a quick snapshot from our balcony the other day.  I think she did a great job.  Especially spur of the moment from an amateur photographer.   I guess those photography classes paid off afterall :)

Do you need a good headshot to be a successful manager?  No.  Do you need one to climb the corporate ladder?  Probably not.  Is it a good thing to have none-the-less?  Probably.

Well now the blog has a real face instead of my simpson-ized avatar.

I'll have another "real" blog posting soon; I've been busy lately with work and other commitments.  Perhaps a blog on time management is in order? 

Wednesday, August 17, 2011

Sunday, August 14, 2011

Defining your management philosophy

“So much of what we call management consists of making it difficult for people to work” – Peter F. Drucker

What is your management philosophy?  Chances are you’ve never really taken the time to articulate it. It may initially seem a waste of time to attempt boiling down all of the intricacies of your management style into a few principles you could label as a philosophy.  However much like a mission statement it does help to communicate to yourself and others those core beliefs that should be fundamental to all of your management decisions.   Taking the time to write out your philosophy helps you learn what it actually is and gives you a foundation to align with when making critical decisions. And it comes in pretty handy when you hire new team members, interview for a new job or take over an existing team.

Unfortunately the vast majority of managers have never given any thought to this at all.  They just chug along “doing their job” as they see it.  They worry about deadlines, deliverables and budgets.  They lack a consistent fountain as the basis for their most important management decisions.  But everyone has some sort of intrinsic management philosophy even if they don't realize it.

Note that I'm referring to management "philosophy" and not management "style".  Your style is more the how and the philosophy is the why.  For example I might describe my management style to be sort of like my poker style:  "tight aggressive".  In other words I can be passive and hands-off, but very willing and able to aggressively get into the details and get things done when needed. But my philosophy (below) provides the reasons for my style. 

When it comes to your philosophy there are no right answers.  As you are well aware there are many different types of managers and many successful managers with very different management visions.  There are countless management theories out there to learn from and I recommend you take some time to look into these.  For example the book As One by Mehrdad Bahai and James Quigley is a good start.   Regardless of how you arrive at your philosophy, the purpose of this posting is to encourage you to spend the time to write one down, even if it’s only a few bullet points. 

Some things to keep in mind as you author your own list of management principles:
  • Start by thinking about what underlying code of conduct guides you in your decisions already.
  • Then think about what is missing or miss-used in your current decision making.
  • Consider what other managers you admire do
  • Use high level principles that can apply to almost any situation
  • Avoid listing things that are general job requirements.  For example “Approving all expense reports on time” doesn’t really fit.
  • It should not be a set of rules with any if/then conditions. You will end up creating rules as implementations of your philosophy.
  • Keep it simple
Today I’m going to undergo this exercise myself and write out a summary of my own management philopshy.  Hopefully this will help you articulate your own.  In the interest of keeping each of these blog articles relatively short I’m not going to talk through my thoughts on different management models today and in the future we’ll get into more detail on how to apply these to every day decisions.

Billy Turchin’s management philosophy

I.                   Leadership:  The best managers are leaders

The best managers are more than administrators, controllers or followers.  They do more than focus on structure and processes.  Instead they are innovators, creators and influencers.  They focus on people and personal development.  This principle guides most of my decisions as a manger.

II.                Enablement:  Employees should be positioned for success

Your team wants variety, learning opportunity and additional responsibilities.  If you fail to provide these you will face decreased morale, apathy or worse.  As a manager you should have a goal for your team members to be successful in their careers and their lives.   Do what you can do position people for this success.  Their success is your success. 

III.             Fairness:  Employees must be treated fairly and honestly

Your employees are people too and as a manager you are no better than anyone else.  People deserve to be treated with respect and honesty.

IV.              Power:  An effective managers recognizes the powers available to them and uses them properly

In a future posting we’ll talk about the five types of power (Legitimate, Personal, Expert, Reward & Coercive) you have as a manager and how to use them. 

V.                 Communication:  Expectations and goals must be clearly set

I’ve found that the majority of conflict and frustration in the workplace results from a misunderstanding in expectations.  The best managers will clearly communicate expectations of their team and of themselves while still giving employees the freedom they need to get the job done.

VI.              Quality:   Quality is more important than process or effort

Effort does not equal effectiveness and quality of work is more important then hours worked.  Processes exist to improve quality but sometimes hamper it.  At the end of the day the output is what should be judged. 

VII.           Be positive

This goes along with (I) but the best leaders are also positive thinkers.  And a little bit of positive reinforcement goes a long way toward employee morale and work drive.  Fake it till you make it?

VIII.        Adapt:  My management philosophy is fluid

Never be afraid of change, even to your own management beliefs.

Shaping your own management philosophy is an important step in defining yourself as a manager.  It forces you to take the time to define and further craft your own doctrine.  When you hire someone new, or takeover an existing team, you can then easily given your directs a clear understanding of your beliefs by reviewing this philosophy with them. 

Every once in a while take a look back at your list to remind yourself and re-align your direction.  Or even keep this bullet point list handy at your desk at all times. Remember that great leaders aren't born that way; you have to work at it!
  


Wednesday, July 27, 2011

Top 10 Management Myths

"Leadership is nature's way of removing morons from the productive flow" Dilbert, February 5, 1995.

The above quote is satirical observation of the Peter Principle from Dilbert cartoonist Scott Adams.  The Peter Principle was published in the 1969 book by the same name and states:  “In a hierarchy every employee tends to rise to his level of incompetence”.  The general idea is that people who do well at their current role will get promoted until they reach a level at which they are no longer competent and there they will stay.  The Dilbert Principle is much the opposite and states that companies tend to systematically promote under-qualified employees into management in order the limit the amount of damage they are capable of doing.  Speaking for those of us individual contributors who were promoted into management, I certainly hope this isn’t true J

Now back to the purpose of this post which wasn’t just a comical history lesson.  I wanted to have a discussion on some misconceptions regarding what it takes to be a manager and how you get there.  You may be thinking it’s silly to be writing about what is management.  After all doesn’t everyone know what a manager is?  And if you don’t, can’t you just look it up on Wikipedia?  (Actually I encourage you to read Wikipedia’s overview on the basic functions of management)  

Well, I am not trying to create my own definition what management is.  Nor am I going to write a big list of all the characteristics that make up a good manager.  That’s been done too many times before as well.  This is not to downplay the importance of recognizing those characteristics and how well you align to them.  However in this post I want to clear up some common myths about management that I continue to see time and time again.  Myths have a way of sticking around, for example “does a duck’s quack echo?”, and with many bad managers come many management myths.  So let’s clear the air on some of the biggest ones in my eyes.  After all, what kind of self claimed management guru could I be without putting together at least one top 10 list?  (Maybe a good one)

So without further adieu here are my top 10 management myths:

Myth 1: Management is the natural ascension of individual contributors

Reality:  The skills needed to be a successful individual contributor (IC) are quite different from those needed to be a manager.  As I mentioned in my Introductions post, excellent engineers are generally mired in deep technical knowledge and lack focus on personal leadership.  Management is not the only path up the corporate ladder.

Myth 2:  Managers make more money than individual contributors

Reality: Managers don’t have to make more than their employees.  People often assume management is the only path to the big bucks.  This may be true sometimes, but not as much as you’d think.  Going back to Myth 1, if someone is an excellent performer who is not interested in going into management, why would they be expected to make less than their manager?  Ultimately people should be rewarded based on their value and contributions to the company.  As upper level managers have an increasing stake in the business and influence over company profitability, they should certainly be compensated well.  However an IC can operate at any level of the organization and also have a big impact on company profitability. 

Myth 3: A manager is a leader

Reality: A good manager is also a leader, but a manager is not necessarily a leader.  One day I will devote a whole posting to the leadership versus management distinction.  In the meantime I like to use the following reference: Consider Jesus Christ.  Regardless of your religious beliefs I’m sure you can recognize that he was a successful leader, but he was not a manager and did not have an org chart.

Myth 4: A manager’s primary responsibility is the project(s)/product(s)

Reality: The primary responsibility of the manager is the people, not the project.  If you are in charge of a printing press you may be accountable for printing pages, but your primary responsibility is really about keeping that machine operational.  Keep your team working efficiently and effectively and the project will follow.

Myth 5:  Managers should make the final call on technical decisions

Reality: Managers make decisions, but they are not experts in everything.  A manager is not always the best qualified person on the team to be making technical decisions.  A good manager should not be able to do the jobs of all of their direct reports better than they do.  While you’ll certainly be involved in technical issues and often making critical decisions on your own, sometimes you also need to recognize the strengths of your team and just trust your directs judgment. 

Myth 6:  Management is easy

Reality:  Being a good manager is hard work.  Often an IC assumes that their manager doesn’t have to do any “real work”; they simply direct others to do the work and delegate.  Sadly this is probably true of some managers, but not in the majority of cases.  A manager has many responsibilities on a personal and technical level to fulfill.  Even delegation isn’t easy as we’ll discuss in future postings.  At the end of the day managers aren’t judged on their individual work as much as they are on the collective work of their team.  And any time your success is tied to the success of others it’s not an easy task.

Myth 7:  You must be charismatic to be a good manager

Reality: While I believe that charisma is a top-tier quality in a good manager, the reality is that many of the world’s most successful managers are not “people-people”.  A good manager treats people fairly and sets up their employees to be happy and successful. Doing this will inspire devotion even without charisma.  And if you are someone that does not have charisma, you can always Fake It Till You Make It

Myth 8:  Time spent managing is time taken from everything else that must be done

Reality:  Time spent properly managing people enables them to be more productive and relieve the burdens of your own deliverables.  Managers often feel like they have their own deliverables to worry about and don’t have enough time to focus on coaching their team.  But when your team isn’t properly managed they are not operating as efficiently as they could.  They could be producing better quality work in less time and be able to accept more delegation from you.  And worse, you end up having to devote a lot of extra time in dealing with all the things that go wrong in a poorly managed team.  By taking the time to position your people properly, they will be more productive and help you out more.  It all comes back to you being successful only when your team is successful.

Myth 9:  An MBA makes a better manager

Reality: An MBA is an excellent tool for those aspiring to senior management and looking to be more involved in the business strategy and financial aspects of the company.  However the art of management is not generally taught in MBA programs.  An MBA teaches analysis and business techniques, but not the skills on talking to people, motivating and bringing true leadership to a team.  While degrees are important, skills and experience trump. 

Myth 10:  Managers must treat everyone equally

Reality:  Managers must treat everyone fairly.  Employees should be treated fairly without discrimination for any reason.  But when it comes time to reward people (and there are many types of reward), performance matters.  If an employee does an excellent job they should be rewarded for it.  And an employee should be reprimanded if necessary.  When it comes time to hand out money, everyone should not be treated equally but instead judged on their performance and their value to the business.  Treat your team as you would wish to be treated. 







Thursday, July 14, 2011

Introductions

Failing organizations are usually over-managed and under-led” - Warren G. Bennis

Have you ever had a bad manager?  It seems that’s like asking, “Have you ever woken up in the morning?”  There’s the micro-manager, the mean-manager, the missing-manager, Bill Lumbergh and more.  Most of us have been in situations where we’ve been unhappy with our boss.  It’s often easy for an employee to berate the faults of their manager.  But what if you are the manager?  How often do you ask yourself “Have I ever been a bad manager?” 

One of the biggest problems I see across industries is that managers don’t spend enough time focusing on leadership and management skills. They are always too busy worrying about deadlines, budgets, deliverables and the enforcement of procedures like time sheets, expenses reports and project status updates.   They don’t study management in the same way they would study a technical challenge.  Managers lose sight of the personal leadership aspect of their job which should actually be their foremost concern.  This blog aims to help address that problem.

I remember when I was young and naive I thought to myself “Managing is easy … you don’t have to do any of the actual work!”  Boy was I wrong.   As I took on more management responsibilities in my career I realized just how difficult it can be.  Many engineers that transition from an individual contributor role to management find themselves in this position.  They have a technical degree and a long career of hands-on engineering work and are then somehow often assumed to be the ideal candidates for management.  That’s not to say engineers can’t be great managers (eh hem), but many are at least initially lacking the training and skills to be effective managers.   If managers can take the time to purposefully study their new craft, their team will thrive and the manager will share in their success.  

When I reached the point in my career when I transitioned from an individual contributor to a manger I was determined not to be a stereotypical technical manager without people skills.  I dedicated myself to exceeding in this role and to constantly be learning and open to change. So I set out to absorb all the information I could through reading, classes, observation and of course lots of practical experience (often involving trial and adaptation).  And so this blog was born out of two purposes:

1)      To share my findings with the world so others may learn and help the development of themselves and their teams
2)     To be a better manager myself by writing and teaching 

This blog will answer many of the questions I had as I was becoming a self taught manager such as:  How do I keep employees motivated?  How do I hire the right people?  How do I keep people properly positioned for success?   How do I determine promotions and raises?  How do I ensure quality?   I will also discuss concerns that I have in my career that I am still working through as my own self training continues.     

Some future topics for this blog include:   Hiring, Orienting, Types of Power, Delegation, Transparency, Risk Management, Agile, Scrum, Interviewing, Salary Negotiation, Promoting, Quality, Documentation, Off-shoring, Remote Teams and much more.

I’ve learned that while many management techniques are universal, there are some attributes to software development that warrant some unique approaches.  The world of software development with its ever changing requirements, technologies and timelines doesn’t make for any less pressure on a new manager.  Most of the topics we cover here will be applicable to most management positions; however the focus will be on software engineering teams and often on transitioning from engineering.

I have no management degree, no books to my name, but I do have a proven track record in building and managing successful software engineering teams and a strong desire to learn and to teach.  I hope you’ll find this blog useful and I encourage your comments to keep this effort collaborative. 

Now back to my TPS reports …