Be a Better Technology Manager

While browsing the deep space of Alpha Quadrant of the web this evening, I ran into a Forbes article entitled, 6 Fundamentals That Can Make You A Better Manager In 2014 by Victor Lipman. I enjoyed the brief article so much, I decided to refactor it into my own words for the manager we either want to be or want to have.

In our agile quest to improve our software and our processes, we may sometimes overlook the nuances of management. In shops with empowered agile teams, it is possible for managers to make management an afterthought, allowing the self-organizing teams to pick up the slack. It is my opinion that this false sense of security and resulting dip in the quality of management can lead to fundamental and long term organizational and cultural debt.

To avoid accumulating this management debt, team members should encourage, perhaps even require, the following from their managers. And certainly managers should strive to focus on these fundamentals even while riding on the success of an empowered, agile development team.

  1. Be open to suggestion. Seek out and embrace ideas and opportunities to improve your management practices. Be a good listener. Take regular one-on-one’s with your direct reports. Conduct “town hall” meetings with your direct reports and their teams. Encourage honest and open feedback. Don’t allow the “way it’s always been done” to overshadow your improvement courage.
  2. Expect excellence and reward it. Set high but attainable expectations. Communicate them clearly. Be gentle but firm and require regular accountability and reporting. Openly recognize and praise success. Privately discuss under-performance and obtain solid commitments to improve from under performing members of your team.
  3. Use your time effectively and efficiently. Be generous but measured with your time. Spend small amounts of planned time socializing with your team members. Be careful not to impinge on their time or waste yours. A thirty second conversation can do wonders for interpersonal rapport but a five minute chat session can degrade efficiency. Protect your schedule. Insist on well run, timely meetings. Focus on your priorities while making a top priority of maintaining a personal connection with your team. If they know you care, they will care when you need them.
  4. Communicate feedback in realtime. Your team needs regular and immediate feedback. This includes public praise for a job well done. It also includes private and direct feedback on unfulfilled expectations with an immediate call to corrective action or a resolution to an expectation that has become unreasonable. DO NOT do negative feedback by email. Back up any positive emailed feedback in person. Real words from a real person mean a thousand times more than an email.
  5. Embrace conflict. Don’t run away from or duck conflict. Hit it head on, in person, and resolve it. Don’t dwell on blame but fairly examine cause and effect and then focus on actions required to resolve the conflict and move forward. Don’t be afraid to apologize or accept responsibility for creating conflicting expectations or misunderstandings. Invite others to suggest ways to improve. Listen and see step #1.

Now go be a better manager. And if you want a better manager, share this or the Forbes article with her or him.

Choosing a Content Management System

Growth in the content management system (CMS) market is strong as more and more companies look for software to help them manage their burgeoning coffers of content. This growth is partly fed by the growing temptation to use these systems for purposes far beyond managing content with CMS vendors tacking on every new feature they can dream up to feed this frenzy. The result is often a bloated, unwieldy, unmanageable, complexity induced bug-infested mess.

I have a relatively high level of interest in this space given my brief professional experience in this market. So I read with interest a post today on the subject by one of my favorite software development authors, Martin Fowler. In his post entitled Editing Publishing Separation Fowler discusses the advantages of separating the editing data and experience from the publishing experience and published data. I invite you to read his article as he makes a very cogent argument which should be taken into account as you consider choosing a CMS.

Before he makes this point, he sets up his theme with this preamble:

"...a regular theme has been the growing impact of content management systems (CMS). They aren't usually seen as helpful, indeed there is a clear sign that they are becoming a worryingly invasive tool - used for more than their core purpose in such a manner that they hinder overall development."

It is precisely this thought which accurately represents my own limited experience in the CMS market. So here are my recommendations for consideration when choosing a CMS for your content management purposes.

  • As Martin suggests, look for a separate editing and publishing experience including separation of data and the advantages that can come from that.
  • And pay close attention to Martin’s opening quoted above. When looking at a feature, such as e-Commerce, consider whether you should be looking at a full featured e-Commerce platform rather than a feature that may have been cobbled onto the product as an afterthought. Remember that your primary purpose should be the management of content.
  • Whether you choose open or closed, open source or commercial, be sure that your own development team can understand and use the system with alacrity.
  • If you have a PHP team, don’t buy a .NET based CMS. And vice versa.
  • Take your time in evaluation. A quick, under-informed decision can cost you far more than you can imagine in future headaches.
  • Give your development team time to find the real problems with the CMS being evaluated and determine whether and how they can live with the problems they encounter.
  • Be sure to test the support and services teams of the vendor if you are going commercial over open source. Or if you are going open source, look for a proven and reliable partner who can guide you through the rough patches. Because no matter which CMS you choose, there will be some of those.
  • Consider licensing and support costs but don’t fall into the trap that open source is free. The efficiency of your own development and content management team using the CMS over the long haul will have a far larger impact on your overall cost of ownership.
  • Ask someone from Missouri to join your evaluation team. In other words, NEVER just accept the word of a sales representative that the CMS she is selling has the feature that you want and that it works as advertised. Like all software, there is a HUGE amount of advertising fluff and endless feature lists. Make sure that you have the sales team “show” you and then make sure that your own development team can make it work without their help and without having to contact support before you accept the claim, “Oh yes, our CMS does that.”
  • And last but not least, do your own research of satisfied and dissatisfied customers. Make some calls. Ask to speak to someone on the evaluation team where another product was chosen over the one you are considering. Ask if they evaluated the product you have your sights set on. Chances are that a few phone calls will land you a gold mine in helpful information.

Of course, you can apply these same principles to purchasing any enterprise software. And you should.

Situational Intelligence Leads to Certainty and Confidence

I like this quote from General Stanley McChrystal on crisis communication:

“I think when any leader faces crisis, this is true on the battlefield but I think it's also true in other areas as well, one of the things you fear most is not understanding the situation. And I think it's that uncertainty that actually is most unsettling to many leaders and causes them to be undermined in their confidence.”

Understanding the situation. If you lack context. If you lack critical knowledge. You cannot effectively lead. First, seek to understand. Listen and absorb. Contemplate. Then, and only then, act.

Goal Oriented Meetings in Software Development

I’m fascinated with the subject of meetings. It is a topic of discussion across the wide webbed world. There are nearly as many opinions on this subject as there are stars in the sky. So adding my own here cannot possibly disrupt our little corner of the multiverse, nor will it likely establish a new or even affect an existing trend. But before I bore you with my own opinion, let me share with you some links to some very cogent resources that have helped me, in addition to my own years of experience, to form my opinions here.

  • Firemen, donuts and meetings – Seth Godin: “Don’t bother to have a meeting if you’re not prepared to change or make a decision right now.”
  • Reduce Meeting Time by 30 Percent – Max Isaac: “Prior to the meeting, send an email with the proposed Purpose, Process and Preparation, and attach documents that should be reviewed.”
  • Meetings frustrate task-oriented employees – American Psychological Association: “…people high in accomplishment striving, who tend to be highly task and goal oriented, were most negatively affected by meetings...
    ...people who participate most in meetings, such as those who identify themselves as upper-level management, tend to view them most favorably...solely because they get to talk a lot, they inevitably miss other key pieces of meeting effectiveness, including their ability to successfully lead the meeting.”
  • Why Goal-Oriented Requirements Engineering – Yu & Mylopoulos: “The identification of goals naturally lead to the repeated asking of "why", "how" and "how else" questions... Stakeholders also become more aware of potential alternatives for meeting their substantive goals, and are therefore less likely to over-specify by prematurely committing to certain technological solutions.” (This paper is not about meetings but contributes to the opinions expressed below.)
  • Goal-Oriented Idea Generation – multiple authors, taken from summary of results: “The goals obtained from the ideas have high quality. During the activities for grouping ideas, it was frequently observed that the stakeholders could find their misunderstandings and tried to resolve them. As a result, the obtained goals were based on the consensus and the agreement of all of the stakeholders.” (Again, this is not about meetings but contributes to my ideas on the subject.)

It has been my experience that any form of software development, including my personal favorite: behavior driven design/development first introduced by Dan North, generally requires more than one person in the process. There is at least a user and a programmer, at least for any software that one might be paid to produce. And where there is more than one person in a process, there is the inevitability of a meeting.

The real question is what is the nature of the meeting. And by nature I mean how will it be planned and conducted, and what if any follow up will occur as a result of the meeting.

Bad Meetings: Vague, Purposeless, Meandering Time Wasters
The world of software developers could fill terabytes of hard disk space with examples of meetings that were a complete waste of time, ineffective, resulted in no change to the status quo nor the discovery of anything that was not already immediately discoverable in an issue or project tracking system.

Rather than go through any of these bad examples in detail, I will simply summarize that these meetings most typically include in the email invite only a vague subject line, a time and place, a dial-in number for remote attendees, and by virtue of the most commonly used tool to send the invite, a list of attendees, most often the entire team. Too many of these meetings and your organization has fallen hopelessly into the “Meaningless Meetings Machine.”

Goal Oriented Meetings: Purpose Driven, Limited, Action Packed
The very best meetings I have ever attended or conducted (yes, I’ve conducted my share of bad meetings too) have had the following qualities:

  • Goal oriented – the agenda focuses on stated goals. (See Mark Schiller’s cogent treatment in Fixing IT Productivity Destroyers.)
  • Limited scope – the time and agenda are limited to specific related goals.
  • Parking lot – good but unrelated ideas go into a “parking lot” to be discussed at another time and often in a different forum.
  • More listening (less talking) – participants listen carefully with their full attention and speak only when they have something relevant to contribute or need clarification in order to make a decision or understand an action item being assigned to them. And NEVER, NEVER, NEVER do participants rudely talk all at once.
  • Previous action items related to goals on the agenda are reviewed in summary fashion – discussion is limited to reporting outcomes and/or impediments that require attention by the group. This does NOT mean that the group attempts to resolve these impediments during the meeting. They are noted and may generate an action item for a participant, but under NO CIRCUMSTANCES will the meeting get side tracked to solve the problem in the moment.
  • Goals drive actions – starting with diverging opinions and working toward consensus in these steps:
    • affirming the goals are properly stated
    • identifying actions required to achieve the goals
    • identifying (or getting volunteers) to take those actions
  • Decisions are made – work toward a consensus but have a meeting leader who can make a final decision right there, right now, after having considered the input of meeting participants. Perfect consensus is not the goal. Decision and action from team input and reasonable discussion is sufficient. (And as Seth points out, don’t bother having a meeting unless you are prepared to change your mind. If you have already made your decision, just announce it, assign the tasks and follow through—don’t waste your team’s time with a meeting to maintain the illusion that you care about what others think—they know you don’t.)
  • Minutes, including action items and commitments, are recorded and published post haste. They are also maintained in a team public place such as a wiki or project portal for reference and follow up.

Goal Oriented Meetings Foster Better Software Development
I included some links already that talk about goal oriented requirements engineering and behavior driven development (BDD). In Dan North’s treatment of BDD, he presents two single sentence templates for defining each of the requirements of any software system. With my own explanations, they are:

To define a feature or user story:

As a [X], I want [Y], so that [Z].

Where [X] is the role of a user, [Y] is the feature, and [Z] is the benefit or value (the goals) of the feature.

And to define the acceptance criteria for that story:

Given [some initial context—the givens], when [an event occurs], then [ensure some outcomes].

The outcomes to be assured also define the goals of the user specifically within a certain behavioral or system state context.

When the goals of stakeholders are clearly understood and can be codified in a manner such as the BDD form, the development team can move forward more quickly and with greater confidence. And when meetings are equally focused on goals and achieving them, meetings will be an asset rather than a liability. And your team will have a much greater opportunity to succeed.

Enterprise Content Management for the Win in 2012

December was an interesting month with multiple pieces on the chess board moving all at once insuring an interesting and exciting new year for me. And that new year is upon us. I picked up my copy of CIO Insight magazine, the November/December 2011 issue, this morning and read with delight the article entitled Where the IT Dollars Are Headed in 2012.

One passage in the study mentioned in the article (included in the print version and linked to online) caught my eye:

“Elsewhere in enterprise applications, collaboration, and content and project management are rapidly gaining popularity, which makes sense given the new mobile opportunities for these categories. Collaboration and content management are seeing increases in 2012 over 2011 of roughly 10 percentage points in the number of organizations budgeting; and among those that already were spending in these areas, budget growths are averaging 14.6 percent and 7.3 percent, respectively—both significantly higher than 2011’s growth.”

I have a recently renewed and very keen interest in the potential growth of the enterprise content management market. And I will blog more about this in the coming weeks which are sure to open up new opportunities for personal and professional growth.

Attracting and Keeping Top Talent in Software Development Teams

A friend recently shared a Forbes article with me entitled Top Ten Reasons Why Large Companies Fail to Keep Their Best Talent which I found informative and useful in understanding my own recent thoughts on this topic. Rather than review each of those reasons here, I encourage you to read the original. Instead I would like to share with you the flip side of that coin based on my own recent experiences.

Attracting Top Talent
Before you can work on keeping your top talent, you have to find them and convince them to join your team. Here are five things you should be doing to attract top talent:

  1. Choose a competent and effective recruiter. This can make all the difference. Don’t just hire an agency and let them blast a job description to every Tom, Dick and Mary of the tech world. Know specifically who is representing your company. Make sure that she knows how to find and filter top talent for you. Ensure that she has the communication and people skills required to manage the phone and in-person interviews and coordinate with the hiring manager to make his job even easier rather than just dumping a pile of resumes on a desk and waiting to get paid.
  2. Do more than one phone screen. Give at least two top team members the chance to phone screen the candidate. Make sure they are prepared and understand what they should ask. Then have one or two managers or potential peers conduct a phone screen as well. Never rely on the resume alone to decide whether you will do a face to face interview.
  3. Have the candidate interview with more than just the hiring manager. Have potential peers and even potential subordinates interview the candidate as well. And when possible, have a peer or supervisor of the hiring manager conduct an interview. Meet with and collect the thoughts and opinions of every interviewer and carefully consider their input.
  4. Assure that every interviewer is positive and upbeat about your company but equally honest and transparent about the challenges and opportunities within the company which the candidate may be able to help resolve or improve. Don’t paint a dismal picture but don’t put a shine on a dull spot. Any intelligent candidate who gets different stories from interviewers will think twice before accepting an offer. Transparency and honesty from the bottom to the top of the company will be a refreshing and attractive quality. And don’t worry about scaring off a candidate who is afraid of a blemish. You don’t want to hire someone who wants to work for a perfect company with no opportunities to contribute to the solutions of the real problems that every company has.
  5. Follow up and answer a candidates questions after the interview process is complete and make a decision as quickly as possible. If you will have some delays before you can make a decision, keep the lines of communication open and keep the candidate up to date. This kind of follow through is often overlooked and companies often take for granted that the candidate will sit still and wait. They won’t. To keep a fish on a hook, as they say, you have to work the line. Let it go slack, and you’ll lose.

Keeping Top Talent
Once you have hired a key employee, make an opposites list from the Forbes article and work toward eliminating the reasons that top talent walks out the door. Of the ten, here are my top picks recast as things you should do to keep top talent on your team:

  1. Give your employees an opportunity to have a voice in key policy and process decisions. Listen to your people with an open mind, prepared to change your mind if you have overlooked something. Your top talent will often have better ideas than you may think.
  2. Take the time to provide regular feedback to your employees. Annual reviews are great, but follow up with periodic reviews of goals, professional development, projects and opportunities for improvement. And always find a way to share positive feedback. When you acknowledge achievements and performance, publicly and privately, you’ll get even more of the same.
  3. Make sure that your team members know that you care about their professional career development. The small amount of time you invest in helping your team map their future success will yield returns in happy, dedicated employees much greater even than the recent gains in the gold market.
  4. Steer a steady ship that can make tactical adjustments in course but is on a solid strategic heading. If you run into stormy waters, keep faith with your employees and stay on course. If you need to make strategic course changes, involve your top talent in that decision making. Getting on a boat headed for Hawaii and finding out that the captain has decided to go to Alaska instead without even talking to you can be more than demoralizing.
  5. Build teams of people who can work well together, who are talented and skilled and willing to pull their own weight and then some. Passionate people will help to bring out the best in team members who are having a bad day, but it is impossible to fix a team member who fundamentally lacks the requisite skills and desire to acquire them.
  6. Be open minded and tolerant of opposing points of view. If you do not invite honest discussion with your team at appropriate times, you will lose your top talent and end up with a team that affirms any decision you make, even those that will send you off a cliff that you did not have the foresight to recognize.
  7. You can teach management skills to a leader. But teaching leadership skills to a manager is not so easy. Look for leaders who can motivate and rally teams. You can hire a clerk or accountant to take care of the bean counting. But you may not recover from having a leaderless team and the resultant chaos and confusion and serial loss of top talent that will result. Do not be afraid to amputate and stop the bleeding. Keeping a failed manager long beyond the point of recognizing the problem to avoid the pain of change is an ominous sign to your top talent that you lack the leadership required to steer the ship successfully to port and they will abandon ship at the first reasonable moment.

If you’re making New Year’s resolutions with respect to your company, I urge you to review these lists, and the plethora of others available on the web from sources far more authoritative than me. Take positive action to attract and keep your top talent. And if you find yourself looking for a company that exhibits these desirable qualities, keep up your search. They are out there. And while no company is perfect, there are certainly some that far and away exceed others. So whatever you do, don’t give up hope of a better day.

Where Agile Succeeds

In the interests of keeping the U.S. Postal Service in business, I subscribe to a number free technology periodicals. I’m too cheap to pay for anything more than MSDN Magazine. One of the free rags I like to keep in the reading room is Information Week.

A recent article entitled Where Agile Fails caught my eye. You can get a copy of it online if you want to hand over your contact info. I enjoyed the article and it makes a good general point. The author Charles Babcock draws our attention to the fact that many agile teams overlook operations and the challenges brought about by frequent releases into production.

I was only disappointed in the title. Any reader who quickly browses the article, allowing the title to influence conclusions, may walk away with the wrong idea. The title would be more informative if less typographically attractive as Where Agile Teams Fail to Involve Operations, Agile Teams Fail.

When agile development is done right, it includes as part of release and sprint planning some elements of deployment, operations, support and maintenance. Some sprints or releases planned may not go into production, so operations need not be involved too heavily, but I think they should be be apprised of the team’s plans and progress and given the opportunity to prepare in advance for the needs of the application and users.

When a release or sprint will go into production, the operations team should be represented in the planning meetings. This will give them the opportunity to learn what is expected of them and plan accordingly. It will also give them a chance to ask questions, raise concerns or even point out why they will not be able to support a go-live date for a release. And when that is the case, you want to know sooner rather than later.

Where agile succeeds is in the notion that people and interactions are more important than processes. The Manifesto does not indicate that it is referring only to developers. Clearly that is not the case. Operations people are people too. Yes, Fred, they really are.

Agile Software Design, Architecture and Planning Tools

Dr. Dobbs published the Jolt Awards for Design, Architecture and Planning Tools today. The Jolt judges make a very important introductory point before discussing the specific winners.

“On large projects, it can be difficult to state requirements, do the design work, and still maintain Agile's orientation towards accepting — even welcoming — new changes from users.

“Those issues notwithstanding, I've noticed that most large or mid-sized projects with mission-critical implications invariably do indeed gather requirements carefully and design the product accordingly. Agile, if it's in use in the organization, typically is most evident in the coding and testing stages.

“Tools that can capture requirements, help illustrate and validate design, and plan the implementation are still very much needed.“

One of the greatest misunderstandings of Agile software development is the assumption that if one thing is valued over another, the thing with lesser value has no value. Let us review the manifesto:

Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right
, we value the items on the left more.

I have added my own emphasis to highlight the point that is so often overlooked by Agile critics and enthusiasts alike. The critic decries Agile for eliminating design, architecture and planning, and yet Agile does nothing of the sort. The enthusiast rushes to write code thinking that Agile is a magic bridge over the need to endure the tedium of design, architecture and planning, and yet, nothing could be further from the truth.

After all, how can you set out to intelligently implement a use case if you do not first fully understand the design and architecture that supports the use case? And how will you know that you are implementing that use case at the right time without proper planning?

As the Jolt judges point out, the design, architecture and planning tools we choose to use in an Agile development shop “must be less heavy than in years past and more easily configured to fit the needs of the organization, rather than implementing a specific methodology to which the organization must migrate its orientation, if not its processes.”

I’m excited to check out the winners the judges have chosen. Visit the link at the beginning of this post and check them out yourself.

Whatever tools you choose for doing your design, architecture and planning, do not make the mistake of thinking that these critical phases of development are eliminated by Agile. You may go about these phases with a new attitude toward what is important and with a more realistic view of the realities of the evolution of a product during all phases of development, but you will not ignore them without significant risk. In fact, I think they need to be embraced by Agile teams remaining focused on the use cases and not the frameworks.