The Dueling Myths of Business

I've never read anything like this before... a fascinating and helpful way to look at the business world

Bad Bosses, Picking Your Fights and Saying 'I Don't Know'

Celebrity CEO Carol Bartz shares some good thoughts

The Five Hats of a Software Development Manager

I've been recently trying to distill what it is a Software Development Manager should be spending their time on. I've come up with "five hats" that we should be wearing -

1. The Leader
2. The Manager
3. The Troubleshooter
4. The Ambassador
5. The Coach

I'm sure these roles are already evoking ideas in your mind. I will go through them one at a time over the coming months, and provide a little more detail.

A good boss can make all the difference

We all know that's true - but how *much* difference, exactly? A study of 23,000 workers in a technology based company has given the answer. The average boss adds 1.75 times as much output as the average worker. And replacing a bad boss with a good boss will increase output by at least 10% (in a 10 man team, that's like having a whole extra headcount!)

What is the most important task a boss should be doing? You might be surprised, but it is teaching/coaching! There are skills you have that your employees need - or if you don't have them yet, you have the time and ability to acquire them and pass them on.

The whole idea of coaching freaks out some Software Development Managers, because their technical skills are necessarily less current than their staff. You shouldn't worry about that - you can buy books or videos for your staff, or send them on training courses.

You have lots of stuff to teach them besides technical specifics. For a start, there's the 20 years of software tips and tricks you've picked up during your software development career. Many of the same problems you were facing back in your COBOL days ;-) are the same sorts of things derailing software projects today. Poor estimation, users who don't know their mind, senior management who won't commit - there really is nothing new under the Sun.

Even outside of project stuff there are things you can teach them, about time management, about dealing with people, about developing their careers, about problem solving, about dealing with difficult clients, about written and verbal communication etc. etc. You can probably add a few more to the list.

Have a look at your calendar tomorrow. How many hours per week do you spend training, coaching and mentoring your staff. One study suggests a good manager spends 20-40% of their time on coaching. That might seem out of reach, but why not start with 5%, and work your way up?

Why honesty is the best policy

Barry Schwartz talks about his new book, "Practical Wisdom".

You Don't Need A Thick Skin

I wish Phil Haack posted a bit more often, as he always has good things to say. His latest post is called You Don't Need A Thick Skin. His main point is that we usually respond to criticism in one of two ways - either we get defensive, or we ignore it (the titular "thick skin"). Sounds about right!

Phil suggest we need to go a third way, and "embrace" the criticism. If someone says your software sucks, try and put yourself in their shoes. And perhaps you will say, "You are right, that does suck. It's not good enough."

As a leader, I'm sure you relate to this. We've all had difficult staff who we've given constructive criticism too, and either they get aggressive or the criticism slides right off. We long for them to take ownership.

But forget your staff - what about you? Do you always have excuses when you fail (and if you never fail, you are not trying hard enough!) Do you grit your teeth when you are criticised, then forget it all once you walk out the door? When was the last time you said to someone, "You are right, this is not good enough. We will fix this and do better."

A world without managers?

Phil Haack feels good - very good - after a year at GitHub. He loves the fact that there are no managers, and wonders if this is the way of the future. He points to the super successful Steam as another IT example of no-managers, and also to Gore & Associates as an example of a large and established company doing the same.

Well, what are us manager types to think of this? Do our careers have a use-by date? Are our days numbered? Well, I wouldn't worry too much. For a start, these ideas are not new. Gore has been running things that way for over 30 years, and it hasn't really caught on. Why? Because it is really, really hard to do!

What about GitHub and Steam? How have they pulled it off? They are both high-margin, high-profile businesses. That is, they attract absolutely top-tier talent, and have the cash to compensate them. Obviously a group of super-smart, super-motivated, super-skilled people are able to get by with loose structures, and still achieve success.

But there is more to the story. Gore may not have "managers", but they still have leadership. Project teams form around "sponsors", who seem to combine project management with product management, though not traditional line management. Gore have also been forced to put in more structure at the upper levels as the company has expanded.

My point is not that GitHub/Steam/Gore are doing something wrong. On the contrary, I think it is very right - for their contexts. I also note that, though they may have abolished managers, they have not abolished leadership. Leadership has good currency, and is always in demand.

The First 100 Days of a New CIO

McKinsey Quarterly set out a plan for the first 100 days of a new CIO (free registration required). The key points are -

1. Start the first 100 days before your first day
2. Clarify and strengthen your mandate
3. Build relationships with business unit executives and agree upon priorities
4. Understand the upside and downside
5. Develop the plan
6. Build your team
7. Rally the IT organization
8. Demonstrate leadership through visible results and actions
9. Continue your personal journey

Leadership 101: Throw People in Over Their Heads and See What Happens

This is pretty straightforward, but true. Note, though - they must be *good* people for this to work. B players will struggle.

Strategy+Business - Best Books of 2012

Strategy+Business magazine have released a list of the Best Business Books of 2012. You need to register to see the reviews (it's free, and well worthwhile), but here is the list itself -

Biography

Eisenhower in War and Peace (Jean Edward Smith)
Steve Jobs (Walter Isaacson)
Birdseye: The Adventures of a Curious Man (Mark Kurlansk)

Innovation

The Wide Lens: A New Strategy for Innovation (Rod Adner)
 Reverse Innovation: Create Far from Home, Win Everywhere (Vijay Govindarajan and Chris Trimble)
Cloud Surfing: A New Way to Think about Risk, Innovation, Scale, and Success (Thomas M. Koulopoulos)

Organisational Culture

Productive Workplaces: Dignity, Meaning, and Community in the 21st Century: 25th Anniversary Edition (Marvin R. Weisbord)
Kill the Company: End the Status Quo, Start an Innovation Revolution (Lisa Bodell)
 Talk, Inc.: How Trusted Leaders Use Conversation to Power Their Organizations (Boris Groysberg and Michael Slind)

Strategy

The New Emerging Market Multinationals: Four Strategies for Disrupting Markets and Building Brands (Amitava Chattopadhyay and Rajeev Batra, with Aysegul Ozsomer)
Pragmatic Strategy: Eastern Wisdom, Global Success (Ikujiro Nonaka and Zhichang Zhu)
Competitive Strategy: Options and Games (Benoit Chevalier-Roignant and Lenos Trigeorgis)

Marketing

Grow: How Ideals Power Growth and Profit at the World’s Greatest Companies (Jim Stengel)
Brand Real: How Smart Companies Live Their Brand Promise and Inspire Fierce Customer Loyalty (Laurence Vincent)
The Intention Economy: When Customers Take Charge (Doc Searls)

Why You’re Not Innovating and What To Do About It

This article from GK Strategic is definitely on to something. Unfortunately, the suggested remedy is not something that fits in easily with established corporates.

The Netflix Culture

This set of internal slides about the Netflix culture was recently leaked onto the net. It's very impressive...

What to do with the performance review?

It's no secret that many people think the Performance Review is sick. After 23 years in industry, I've heard these reviews criticised far more often than they have been praised. Most people treat them like a bit of necessary, but useless, administrative overhead. This is a great shame, as most people crave feedback. What an ironic situation!

Atlassian have bumped up against this situation, and have overhauled their performance reviews. This involves two main things -

1. Abolish an overall rating, and replace it with a two dimensional graph that focuses on the frequencey of "outstanding performance" and "stretching yourself".
2. Abolish individual staff bonuses. People are top market dollar, and then share in a company-wide bonus if targets are met

Regarding point 1, they have really replaced one rating system with another. The crucial difference, to my mind, is that the new rating system focuses on "frequency" of the desired behaviours, rather than just a blank score. It is much easier for someone to agree that they "didn't stretch themselves often enough", than to agree that they are a "below average" performer. So this might feed into more honest discussions.

Regarding their new approach to remuneration, I also agree. Tying bonuses to company performance gives people a real stake in the bottom line. Of course, this is not really innovative, but I think they are moving toward best practice here. I suspect you will find that people get different bonus shares as well, so perhaps it's not quite as progressive as it sounds!

Atlassian admit they are flying a bit blind with these changes. They put these changes in place nearly two years ago - I wonder if they have posted up a retrospective?

Art and Philosophy of Software Engineering

There are some helpful ideas in this...

Top Tech Trends for 2013

Gartner have just released their list. It includes -

1. Mobile devices
2. A long-term shift from native apps to Web apps as HTML5 becomes more capable
3. The personal cloud replaces the notion of personal computer
4. The Internet of Things
5. Cloud computing
6. Strategic Big Data
7. Actionable Analytics
8. In-memory Computing
9. Virtual appliances integrated ecosystems
10. Enterprise App Stores

I am back...

My apologies for letting this blog lie dormant for over 3 months. I was up to my elbows in work and university at night. My subject was "Strategic Leadership for Innovation". Very interesting! But lots of work. The good news is that it gave me lots of new material. I'll try and post a bit more often over the coming months.

Why Human Multitasking is Problematic

The Siren Song of Multitasking

Using Business Analysts with Scrum

There has been increasing attention paid to the role of Business Analysts in the Scrum development methodology. Feedback from some early adopters of agile methodologies seemed to suggest that the role of BAs had been made redundant via the use of short feedback cycles. Certainly I can find no mention of BAs in some of the seminal agile books like "Extreme Programming" and "Agile Project Management with Scrum".

The death of Business Analysts has been greatly exaggerated. A quick google will show you that BAs with agile experience are in great demand.

Let me tell you how we use BAs with Scrum. Usually the Scrum Master meets with the Product Owner before the sprint planning meeting to "groom" the product backlog. We push that meeting back to a week or more prior to the planning meeting (we are on month long sprints) and send the BA to meet the PO.

In addition to grooming the backlog, the BA digs into each of the user stories in more detail. He then goes away and prepares a specification based on the priorities identified. This spec is usually complete by the time the sprint planning meeting occurs, and is used for estimating and after that as a development spec. Toward the end of the sprint, the BA then tests the system against the requirements.

You've probably got some questions -

• How big are these sprint specs? We have four developers in one of my teams, our sprints are a month long, and the sprint spec is usually about 20 pages long.
• What's in the specs? We make use of Gherkin, and also screen prototypes done in Balsamiq. We also do acceptance criteria for each user story.
• What do programmers think of the specs? They LOVE having specs. Rather than having to ring up the PO all the time, they can just get on with the coding. When a BA is on holidays and there are no specs available, they are not happy.
• Have the specs improved the quality of what you are building? I think having specs, acceptance criteria and tests against those criteria have certainly reduced the number of bugs in the code, and stopped us going down dead ends.

Ok, you say, so it's been effective. But you might have some other objections -

• Doesn't writing specs violate a cardinal agile principle? The Agile Manifesto says that we should value working code over documentation. I agree! However, it doesn't say we should have *no* documentation, just that we shouldn't create these huge specs and spend all our time trying to keep them up to date. We don't do that. We create a spec per sprint, and it's really a disposable document, forgotten once the code has been written.
• Aren't you just describing the role of the Scrum Master? The Scrum Master certainly does requirements analysis in classic Scrum. However, I don't believe it is usually to the detail and quality that a professional BA will give you. I've also found that Scrum Masters are usually far too busy to spend time doing the requirements in detail.
• Don't you lose agility? I don't see why you would. The specs simply reflect the priorities the PO has set - they don't change them. And the specs are a guide, not a shackle - if something doesn't work out when it comes time to code, there is no problem with trying something different.

I hope I've shown you how useful Business Analysts can be on a Scrum project. I couldn't live without them now.

The Care and Feeding of Software Engineers

I've only just skimmed this article, but from what I read, it has a lot of useful insights. (click here)

Punctuality and Respect

The following Dilbert cartoon rings true - click here.

Sadly, I've seen this attitude in many companies, especially a couple of large mutli-nationals I used to work for. Managers were perpetually late to team meetings. As the Dilbert cartoon suggests, this really shows a lack of respect for your subordinates, the message being that their time is not valuable.

As a manager, you should be competent at organising your time. Make the effort to be punctual with your staff - they will appreciate the respect.

Autonomy and Motivation

Daniel Pink has identified autonomy as one of the key intrinsic motivators. That is, if we have a complex, creative task to perform (like software development), we enjoy it more if we are given the freedom to make real decisions. From long experience, I have observed that programmers value autonomy almost above anything else. Programming is fundamentally problem-solving - if you put too many restrictions into the process, you rob it of much of it's joy.

So how do we establish autonomy in the workplace? Kenneth Thomas identifies the following building blocks -

1. Delegated authority - the right to make decisions
2. Trust - confidence in an individual's self-management
3. Security - no fear of punishment for experimentation and honest mistakes
4. A clear purpose - an understanding of what one is trying to accomplish
5. Information - access to relevant facts and sources

These are pretty clear, I think. The opposite approach is known as "micro-management", and it is loathed by programmers. I've known managers who insist on personally inspecting every line of code written by their subordinates. This sort of thing simply destroys motivation.

Does this mean we are left with a free-for-all? Not at all - everyone understands there needs to be boundaries, and these are often captured in standards and practices documents. Ideally these should be negotiated up front, and the relevants parties should "buy in" to whatever boundaries have been established. Then, so long as the boundaries are respected, the programmer ought to have autonomy.

One of the reasons I like Scrum is because it establishes and protects programmer autonomy. In a proper Scrum, the development team must agree to the amount of work to be done in a sprint. Furthermore, once the sprint has started, it is up to the team to implement the functionality as they see fit - neither the Scrum Master nor the Product Owner are permitted to interfere. And teams are highly motivated to complete a piece of work that they voluntarily agreed to - much more so than a schedule that is imposed by fiat.

Granting autonomy is not hard for "Big Picture" people - it is much more difficult, I think, for detail people, who want to know and control every little thing. If you are guilty of micro-management, I'd encourage you to change your course - the impact on motivation will be spectacular.

Seven Roles of a Leader

These are quoted from Kimball Fisher's excellent book, Leading Self-Directed Work Teams -

1. The leader unleashes energy and enthusiasm by creating a vision that others find inspiring and motivating.

2. The results catalyst helps the team improve performance, gets good results without resorting to authoritarian methods, manages people by principle rather than by policy, and uses boundaries rather than directives.

3. The facilitator brings together the necessary tools, information and resources for the team to get the job done, and facilitates group efforts.

4. The barrier buster opens doors and runs interference for the team, challenges the status quo, and breaks down artificial barriers to the teams performance.

5. The business analyst understands the big picture, is able to translate changes in the business environment into opportunities for the organisation, and acts as an advocate for the customer.

6. The coach teachers others and helps them develop their potential, maintains an appropriate authority balance, and ensures accountability in others.

7. The living example serves as a role model for others by "walking the talk" and demonstrating the desired behaviours of team members and leaders.

The Scrum 3x3

I've published a new and improved version of this article on LinkedIn. Click here.

I've been developing software professionally for over 20 years, and project methodology has been a perennial problem in the industry. In the mid-90s it seemed like a new methodology was being devised every other week, and none of them seemed to deliver what was promised. I think I came to the implicit conclusion that software project management was an intractable problem.

If you had told me back then that a new methodology would soon come along that would be adopted by perhaps 80% of commercial companies, with many people reporting great success, I would scarcely have believed it. Yet that is exactly what has happened with Scrum.

Let me admit up front that I am a fan of Scrum, and I want to discuss it in future posts. Now, I'm not really interested in the Quest for the One True Scrum, and nor do I want to participate in the Scrum Wars. But I thought I should at least share what I believe Scrum to be.

Essentially, to be doing Scrum you need to have the following 3x3 -

• 3 Roles - Scrum Master, Product Owner, Team Member
• 3 Meetings - Sprint Planning, Daily Scrum, Sprint Review/Retrospectivve
• 3 Artifacts - Product Backlog, Sprint Backlog, Burndown Chart

The whole process is well captured in this image -

And that's it. If you are doing anything less than this, I would suggest that your methodology is "Scrum-like" but not Scrum. If you are doing anything more, good for you.

Why this blog?

I thought it might be helpful to explain the purpose of this blog. I started it for three reasons -

1. I agree with Scott Hanselman that software professionals should have a public blog, a place where they share ideas, opinions and lessons learnt. Software development is difficult, and will be even more so if we don't share our knowledge.
2. I've recently commenced a Master of Business in IT Management, and this will be a place where I can reflect on what I've been learning.
3. I wanted to fill a bit of a gap in the knowledgesphere. There is plenty of information online about software project management, but very little about managing software developers. Indeed, the only other blog I'm aware of in this space is Rands in Repose (and a good read it is, too). Hopefully I can encourage a bit more discussion in this space.

More on Motivation

Click here for a new and improved version of this article.

Have you seen the animated video called Drive: The surprising truth about what motivates us? If not, you should check it out now. The video is a summary of a book by the same name by Daniel H. Pink. His thoroughly researched thesis is that extrinsic motivators (the proverbial carrot and stick) are not effective when applied to jobs requiring intelligence and creativity - jobs like software development. Pink proposes that intrinsic motivators are much more effective in these instances, and he identifies three - autonomy, mastery and purpose.

There was a big "a-ha" moment when I first encountered this idea. Looking back over a long career in software, it is plain to me that the most ineffective managers have been those who relied most strongly on an authoritarian "punishments and rewards" approach. The same experience suggests that Pink's three intrinsic motivators are spot-on with regards to software developers.

I've previously discussed the idea of purpose at work. In future posts I'll examine autonomy and mastery, and how these ideas can be applied to create a great environment for software development.

Key Leadership Tasks

Leadership is a complicated idea, and defies over-simplification. Still, the following four pronged model is as good a description of the strategic leadership task as I have seen -

1. Establishing the organisational Core (mission, vision, values)
2. Aligning organisational structure/culture with the Core
3. Managing power constructively
4. Stewarding renewal

This model was devised by Ken Dovey, from the School of Systems, Management and Leadership at UTS. In future posts I'll reflect on how I see these ideas playing out in software development groups.

Purpose and Motivation at Work

What drives your staff? What motivates them to turn up each day? Some will say it's all about the paycheck. This is undoubtedly true in many cases - yet it is not satisfactory for anyone involved. You will never get the best from your team if it is only about the money. And, by definition, your people will not be enjoying their jobs much either! It follows that finding better motivations for work will be good for you, and good for your staff as well.

Mourkogiannis (2007) identifies four "moral traditions" that potentially give purpose to individuals and organisations. These are discovery, excellence, altruism and heroism. I'll discuss each in turn.

Discovery

This is the desire to have new ideas, think new thoughts, and learn new things. This drive is often found in those doing research at university, or plugging away in cutting edge start-ups.

Excellence

This is the desire to create products of the highest quality possible. Think of Steve Jobs and Apple. This drive can be found in any organisation - alas, it is all too rare.

Altruism

This is the desire to better the human race. It often drives those that work for NGOs and other charity organisations. It's a little harder to tap into for those of us in commercial organisations.

Heroism

This is the desire to be the "very best" at what you do. It differs from excellence is that the focus is on your own ability rather than what you are producing. A potentially dangerous drive that can border on narcicism, yet I believe it can be legitimate with an appropriate amount of humility.

As managers, we want to try and tap into these higher motivators, so that our team are not simply turning up to collect their paycheck. Does a team member lean toward any of these drives? If so, what can you do to support and nurture this inclination?

---

Mourkogiannis, N 2007, 'Purpose: The starting point of great leadership', Leader To Leader, 2007, 44, p. 27

Good to Great (Jim Collins)

Good to Great is a mega-bestselling business book by Jim Collins. His thesis is that there are several identifiable characteristics common to "great" companies - by which he means companies that greatly exceed market average returns over a period of 15 years. Collins identified the following lessons from these "great" companies -

1. Level 5 Leaders - appoint leaders who blend personal humility with strong professional will
2. First Who...Then What - focus on getting the right people on the bus, then figured out where to drive
3. Confront the Brutal Facts (yet never lose faith) - Be excruciatingly honest about your current position, but keep believing you will prevail
4. The Hedgehog Concept - focus on doing one thing very well
5. A Culture of Discipline - be disciplined in everything
6. Technology Accelerators - use technology to accelerate change, rather than igniting it

Collins attempts to show these lessons have been empiracally derived from the data. I don't think he quite makes his case, and I certainly don't believe this is the magic formula to success that Collins claims. But the concepts are generally sound, imo, and are illustrated by interesting case studies. It's a useful book that will prompt many to re-examine their leadership style and strategy.

Open The Front Door

This is a helpful little management technique you can use when you want to change behaviour. It's called "Open The Front Door", which is a mnemonic device for the four step process - "Observe Think Feel Desire".

The first step is to state what you have Observed. For example, "I saw you slam the door."

Next step is to describe what the observation made you Think, that is, what conclusions you drew. For example, "I thought you must be angry with me".

Third step is to state how this makes you Feel. For example, "This made me feel sad and hurt, and a bit angry myself."

The final step is to state what you Desire, what you want to happen. For example, "I want us to be friends again."

It's a simple tool, but surprisingly effective in practice. Here's what you might say to a staff member who is on the Internet too much -

"Hi Jenny, I've observed that whenever I walk past your desk, you always seem to be on Facebook. This makes me think that you either don't have enough work to do, or you have work that you don't want to do. I feel frustrated by this because there is a lot to be done, and everyone else in the team is working really hard. What I desire is for you to be fully productive during work hours. How can we achieve this?"

You don't have to use the exact keywords, of course - equivalent words are just as good, and might suit your style better. Some people might think such an approach is too confrontational, but I've used this technique a number of times, and found that it really helps open up effective communication. Give it a go...

Why Microsoft will win the tablet war

Microsoft looks dead in the water with regards to the tablet war. Windows 7, though a stellar OS for PCs, is far too cumbersome for tablets, and Win7 tablets have been non-starters. Windows 8 will run on ARM processors, and has been optimised for tablets - but it is not due to late this year, possibly next year. This gives Apple a massive lead, and even more time to consolidate their market dominance. The only serious competition at this point is Android, which is just starting to get serious in the tablet space.

Given this, it seems outrageous to suggest that Microsoft will one day dominate the tablet space. Still, I think it will. Firstly, history has shown that it is very foolish to write Microsoft off. I remember very clearly in the late 90s that people thought Netscape (and the internet) would destroy Microsoft. Seems laughable now, with Netscape just a distant memory, but people honestly thought that. Microsoft was very slow out of the gates with the internet, and instead messed around trying to build a proprietary public network. But once they realised what way the wind was blowing, they quickly made up ground and continued to dominate the OS scene throughout the noughties. In technology, it is very common for an early market leader to lose what seems an indominatable market position. Hello, Blackberry?

Next, you need to consider the Steve Jobs factor. Jim Collins in "Good to Great" found that rockstar CEOs tend to leave behind companies that struggle without them. With Jobs, you have the typical rockstar CEO with the volume turned up to 11. Apple customers weren't just buying into a product line, they were kinda joining a cult. Can the cult survive the death of it's guru? I'm doubtful in this case.

Lastly, we need to consider the advantages a well designed Windows tablet would have. The same cost dynamics that drove down the price of the original Wintel PCs would be at play, and so we can expect tablets at much cheaper prices than are currently available (my guess is that the magic number is about $250 for an entry level tablet). Business would jump on such a tablet in a way that they haven't with the iPad. The 90% of home users currently running Windows will be more tempted by a compatable machine. And there will be a heap of software (good and bad) flooding the market pretty quickly, free from Apples tightly regulated content regime.

All up, even if the first Windows tablet doesn't get here until 2013, and even if it is not that good, I would lay odds that MS will eventually win the tablet war.

Leadership Without Excuses (Grimshaw and Baron)

I've been reading a few management books lately, but this one is the best so far - Leadership Without Excuses. Not only is it well written, it is intensely practical, and it's obvious that they guys have been there, done that, bought the t-shirt. The chapter headings alone show you they know their stuff -  

1. Equip your people for moments of truth and tradeoff
2. Invest excruciating minutes to ensure role clarity
3. Use commanders intent to promote ownership. Stretch your people. Align them with your business strategy
4. Compete for attention
5. Boost the credibility of your high expectations
6. Reward what you want to see more of... and stop tolerating what you don't
7. Use the other F-word to tap hidden sources of motivation
8. Wield your biggest stick: the power to take things away
9. When you have no authority - use increased confidence and reduced anxiety as your consequence currency
10. Whet the appetite for truth
11. Prevent excuses before they happen
12. Banish the fantasies and fetishes that lead to fingerpointing
13. Treat mistakes as intellectual capital and give negative feedback that doesn't freak people out

What makes a great workplace?

Some time ago, Gallup initiated a multi-year workplace satisfaction survey, covering hundreds of thousands of people. They came up with a list of 12 core dimensions that are consistently present in great workplaces. As a manager, get these right, and there is a good chance your people will be very satisfied -

1. I know what is expected of me at work.
2. I have the materials and equipment I need to do my work right.
3. At work, I have the opportunity to do what I do best every day.
4. In the last seven days, I have received recognition or praise for doing good work.
5. My supervisor, or someone at work, seems to care about me as a person.
6. There is someone at work who encourages my development.
7. At work, my opinions seem to count.
8. The mission or purpose of my organization makes me feel my job is important.
9. My associates or fellow employees are committed to doing quality work.
10. I have a best friend at work.
11. In the last six months, someone at work has talked to me about my progress.
12. This last year, I have had opportunities at work to learn and grow.

8 Habits of Highly Effective Managers

These were put together by Google. Some good advice...

1. Be a good coach

• Provide specific, constructive feedback, balancing negative and positive
• Have regular one-on-ones, presenting solutions to problems tailored to the employee's strengths

2. Empower your team and don't micro-manage

• Balance giving freedom to your employees while still being available for advice
• Make "stretch" assignments to help them tackle big problems 

3. Express interest in employees' success and well-being

• Get to know your employees as people, with lives outside of work
• Make new folks feel welcome, help ease the transition 

4. Be productive and results-oriented

• Focus on what you want the team to achieve and how employees can help achieve it
• Help the team prioritize work, and make decisions to remove roadblocks

5. Be a good communicator and listen to your team

• Communication is two-way: Both listen and share
• Hold all-hands meetings and be specific about the team's goals
• Encourage open dialogue and listen to the questions and concerns of your employees

6. Help your employees with career development

7. Have a clear vision and strategy for the team 

• Even amid turmoil, keep the team focused on goals and strategy
• Involve the team in setting and evolving the team's vision, goals, and progress 

8. Have key technical skills, so you can help advise the team

• Roll up sleeves and work side-by-side with team, when needed
• Understand the specific challenges of the work