Should You Be The Smartest?

Should you, the leader (think manager, director, VP, etc.), be the best technically on your team?

I struggled with this early in my management career. When I managed teams with excellent developers, I felt a need to show them I could get down and dirty into the code. Periodically, I'd make minor changes just to show them I "still had it."

However, technology changes.

Fast.

The only way I could remain competent in technology was at the expense of my manager role. So here I was, facing a dilemma: To manage technical folks, I had to remain technically at the top. To remain technically at the top, I couldn't spend time managing.

So I did what we used to do when we coded ourselves into a circular loop.

I hit control-C and stopped my internal “programming”. I gradually developed new internal programming.

My management value isn’t determined by being the smartest technically on the team. It is based on recruiting and retaining people technically superior to me. More than that, it is developing each of them to grow in their professional (and yes, personal) lives. This recognition changed my relationship with my teams. Most importantly, it freed me from having to prove my technical skills every day.

Instead, I could focus on learning the business in order to help my team make better technical choices. That’s right - in order to get the most out of a technical team, I had to transform myself into a business leader.

You may be saying to yourself (and the many friends who are certainly huddled around your monitor as you read this), “You have to be technical to manage technical teams. That is the only way they respect you.”

I would agree – to an extent. I’m not suggesting that you ignore technology. It is a matter of focus. Instead of spending days writing code, consider the value of time spent learning your business and what your customers are attempting to achieve. You then have an opportunity to return to the technical discussion with a perspective that your team members may not have (as a complement to this, see my post on building customer facing teams).

Keep in mind that many successful coaches were great players. But when their teams won the championship, they were on the sidelines, not the field.

History: Its there for a reason

I recently had discussions with several senior engineers about “modern” software architectures. The conversation turned to service-oriented architecture. While discussing the merits of SOA principles, I was struck by their consistency with principles developed 30 years ago or more. For example, fundamentals such as information hiding, modularity, and coupling. These are time-tested principles that have been the foundation of major evolutions in software architecture since the 1970’s (and perhaps earlier).

Don’t get me wrong – I’m not suggesting that SOA is merely a new name for old concepts. The SOA discussion was merely a trigger for me to consider how we, as practitioners of our discipline, learn from and incorporate lessons from our past. My observations have led me to believe few development folks spend much time seeking and learning from the past. For example, how many members of your team have heard of Fred Brooks, Jerry Weinberg, Tom DeMarco, Dave Parnas, Barry Boehm, Watts Humphreys, and many others who paved the trail for large system software development and managing teams? Of those that have heard of these people, how many can articulate the key concepts and contributions these folks have brought?

Let me fast forward to my point, or more accurately, my question to you. What are you doing to know the history of software development, and what are you doing to encourage your team members to do the same?

You may ask why I seem concerned with lessons that are in some cases 35+ years old. I would tell you that the variety and depth of reading/learning I’ve done has served me well.

New technology doesn’t appear as “new”. Process innovation looks more like a natural evolution of what I know, versus, well – innovation. I view emerging technology and practices with a critical eye of “how is this like what I know” and “to what degree does it differ”, as opposed to “wow – I have to learn a whole new (insert your favorite thing that will be obsolete in 5-10 years).”

By learning about software engineering history, I have at my fingertips some of the best and worst methods that have been learned in the trenches. That gives me a much broader experience base than what I would have if I limited myself to only what I’ve seen firsthand. This in turn, increases the set of responses available to me when faced with “new.”

So next time you are looking for a new book, consider an “oldie-but-goodie”. You might just find that someone has grappled with very similar problems years ago that you are facing today.

Building Customer Friendly Teams

How do you develop wonderful user experiences if your development team has contempt for your users?

OK – I admit this may be a bit strong. But bear with me for a minute.

Think about your development team – top to bottom. Do you have folks that refuse to talk to customers? Or folks that insist they know what the customer needs, even though they have never spoken to a customer?

I’ve seen this across every company I’ve worked for, and at all levels. Sometimes it was an engineer who knew that a user “would never do something that way”. Other times it was a development leader who believed it is “Product Management’s job to talk to customers.”

In either case, you, your company, and your customers lose. I’m not going to discuss you all lose – that is better left to a different post. After all, I’m writing this post under the assumption that you want to create a customer friendly team. With that, let me share some guidelines that can help you build a customer friendly development team.

Set the tone
As the leader, you set the tone that the customer is the highest priority. In practice, this means you:

• never disparage your customers (e.g., refer to them as ‘dumb users’, etc.).
• always include customer considerations in product decisions (e.g., this feature will make our users more efficient, happier, etc).
• show respect for your customers in every interaction with them, even if your team members aren’t there.
  

Find opportunities to teach
Bring members of your team with you to visit customers, to observe end users, and to attend conferences. These are excellent environments to role model. I especially find it helpful to debrief team members on why I acted a particular way with a customer.

For example, I may agree to add a certain enhancement on behalf of a customer. I’ll share with my team member the background on why I made the commitment. For example, perhaps the request was already in the queue and will generate goodwill for a very vocal customer, at very little impact to the roadmap. Or perhaps this is a customer who provides tremendous references and has “earned” the right to get small requests periodically.

These interactions serve to teach team members that more goes into product decisions than technical decisions. This is the basis for developing future business leaders. Keep this in mind - most (all?) successful C-level people handle customers exceptionally well. Chances are they learned that skill somewhere along the way. Why not give a future CEO the chance to credit you with their success!

Expect user interaction from your team
I expect every member of my team to interact with users. That expectation drives all team behavior from hiring through annual reviews. Every one of my managers had goals associated with attending user groups or customer visits. That, in turn, set the tone for their direct reports.

As a result, team members look for opportunities to get out with customers. There are even team members who reach out to customers on their own for input during the development process. Not only does the person get great input, the customers who were asked develop greater affinity for your company and “their” product.

The investment you make in creating a customer friendly team pays dividends:

• Increased customer loyalty (Customers tend to give you the benefit of the doubt if they know you and your team care about them and their challenges)
• Better decisions (Who better to know how a feature can work best other than the people who do the job every day?)
• Higher maturity teams (Technology takes place in a context – and the context is the customer environment, not the SDLC)

Now go out and find a customer to meet.

Building Process Scalability into Software

We often associate scalability with system response time. There is another aspect of scalability that is often ignored until too late. Ironically, it is perhaps one of the easiest aspects of scalability to address before any code is written. I'm referring to scalability of the software to support large, complex processes that touch many people.

Here are two examples:

• Adding large numbers of something to your system at one time. For example, users, payments, or products.
• Making administrative changes across many items. For example, changing permissions for many users, adjusting process to many items, or applying payments to many customer accounts.

I've noticed most software appears to be designed for entry of one new user, changing one product, and so on. This works well most of the time. However, two things usually happen:

1. A customer grows so large that updates happen frequently enough to start impacting productivity. For example, posting a customer payment by hand may be reasonable if you get a few payments a day. What happens for a multiple location business with centralized billing and dozens or even hundreds of payments?
2. Periodic bulk changes consume very large amounts of time and effort for a short period of time. New laws and across the board price adjustments are examples of things that may occur only once or twice a year, but have to be done for many, many items in a very short period of time.

Scalability in this context means scalability of process. It may be fine that it takes 30 seconds to increase the price of one product by 5%. But what if I need to increase the price for 10,000 products? You are going to have to provide me an efficient way to do this.

Unlike hunting down slow performing algorithms, you have to apply user experience principles. Identify operations your users perform to large numbers of items. There are three questions that arise from this:

1. Who are your users and what are they trying to accomplish? From here, identify the most critical operations that are performed frequently.
2. What does “perform frequently” mean to them (not you). Something that is performed once daily, but takes 30 minutes may be frequent to your user. This is especially true if it is something that they will likely do more frequently if their business grows.
3. How big is "large numbers"? For some things, 3-5 times may be a large number if each time it take 2-3 minutes. In other cases, it may be hundreds of times, even if each time takes a few seconds.
   

Seconds add up
Saving one person 2 hours per task, when it is performed 10 times per week, is easy to understand. Be careful to not overlook an opportunity to save 30 seconds of a 2 minute operation when 10,000 people perform it 2 times a week. I've used somewhat extreme examples to make a point - not to set a standard. The core point is that saving time from seemingly small operations for many users can provide a very real net benefit to your customer over time. Don't overlook those opportunities, even if the savings seems small initially.

These lessons can be applied very early in the development cycle - well before any code has been written. The observations made through interacting with the users allow you to focus energy on making your customers efficient with your software, even if that means slightly fewer features.

Keep in mind - you are likely to be better off with fewer usable features than a lot of features that are inefficient. And let's not fool ourselves - once a feature is released we seldom go back and improve it proactively. Take the time to build in support for scalable processes along with all the other "ilities."

Hire for attitude

I was chatting with someone the other day (as opposed to chatting with myself - but that is another story...) about the state of talent in our industry. I relayed to him a quote I learned from Michelle Jackman (http://www.mjbizwiz.com/) many years ago: Hire for attitude and train for skills.

Given that I heard this from Michelle in 1988, it is among the most impressionable things I’ve learned in my career. Along the way, I’ve discovered a few things that help me assess a potential team member’s attitude. This is not an exhaustive list, and I welcome your thoughts.

Focus on principles, not tools
The best candidates (and subsequently, hires) have been the ones with whom I’ve had a conversation about software engineering fundamentals and principles. How do they view design? How do they view build management? Does the art and discipline of software development excite them? If none of this matters to them, I don’t care if they know languages and data structures.

You may be asking, “How do you know if they actually have skills, though? These sound like philosophical conversations.” You are correct - they are about philosophy. However, if you dig deeper, you’ll realize the candidate has developed their philosophy through their experience and learning. A candidate can’t talk to me intelligently about multi-branch, concurrent release management unless she has dealt with it in her career. I don’t necessarily care if she has used CVS, Subversion, Jazz, or ClearCase. What I care about is that she experienced the challenges with this and has developed principles about release management that are consistent with (or will add to) mine.

In addition to software engineering principles, a person must love to learn. I ask things like what websites and journals they subscribe to. I ask them what the last couple of books are that they’ve read. Candidates that come up blank are not asked back. If the candidate shows no interest in learning on their own, they aren’t going to be fit on my team.

Focus on customers, not process
I want to know if the candidate wants to be left alone to code or understands that we build software for people. If the candidate shows little to no interest in the customer, they don’t get on my team, regardless of talent.

I had a key senior architect who I wanted to accompany me on a customer visit. This was a key customer, with a team of highly technical staff. My guidance to my architect consisted of something like, “We are visiting customer ABC, to discuss our foo-bar capability. They are going to have several of their technical folks at the meeting. I want you to discuss our architecture with them. Take care; I’m on the road for the next couple of weeks. See you at the customer.”

He prepared customer friendly architecture drawings. He kept me posted on progress and asked my thoughts about the overall level of discussion and breadth of topics. In other words, he demonstrated the attitude that customers are important, and that we need to be prepared when meeting with them. That attitude, by the way, was infused into his designs.

His response was exactly what I expected based on our conversations during the hiring process. My faith in him was not drawn from his technical ability (although it was very high). It was drawn from knowing his attitude about software engineering and customers.

Concluding example

I once was approached by a person who wanted to join my team. He was a developer earlier in his career and then a manager for several years. He realized he was happier as a developer and saw an opening on our team. On the surface, there was no reason to hire him. He hadn’t developed in years and was pretty rusty with his technical skills.

Since this was an internal candidate, I took him to lunch as a courtesy. In the course of the conversation, I was impressed with his work ethic, empathy for the challenges of management, and his strong customer-centric approach to software development. Late in the conversation, I told him flatly that I loved his attitude, but had concerns about his ability to develop after being out of it for many years.

He assured me he would spend his own time re-learning languages and environments. This was one of those “look a person in the eyes and judge whether he is sincere or not” moments. I judged him to be sincere. He went through the rest of the interview process, and we agreed to hire him, strictly on attitude. After all, how often do you get a chance to bring someone with management experience and a customer focus onto your development team?

Results? He became one of our most trusted developers. He won company awards and frequently was asked to personally address issues with top customer accounts. His attitude of self-motivation, customer focus, and results were the keys to his success. Yes – I could have hired a person with a couple years of programming experience that on paper would have “coded circles around him.” But the results would not have come close to what this person delivered in his years working for me.

Think about how you acquire talent. Do you engage candidates in meaning dialogue about learning, customers, and principles of software engineering?

Help Sales Sell

I recently attended my company’s global sales kickoff. It afforded me an opportunity to observe our products from a different perspective. From a developer’s perspective, a product is a sense of personal accomplishment and a source of pride. From a customer’s perspective, a product is a way to increase pleasure, productivity, or revenue.

What is a product from a salesperson’s perspective?

To a sales person, a product represents their livelihood. If there is no product, there is nothing to sell. If there is no sale, there is no commission. Let me be clear here – there is absolutely nothing wrong with selling to make a living. That would be as silly as asserting that “all developers want to do is get paid to write software.” My point is that being able to sell a product is more than just pride – it is what pays their bills. And, in case you haven’t figured it out – your bills, too.

Luckily, these perspectives are not mutually exclusive. I’ve written quite a bit in this blog about why customers matter. I’d like to turn my attention to our sales colleagues. I’ll start with what should be an obvious statement: sales people pay our salary. That alone ought to be enough to look at sales in a different light.

It is a running joke in software organizations that development and sales are destined to be at odds with one another. I admit that I’ve bought into this belief to various degrees through the years. I’m starting to see things differently. Being surrounded by hundred of sales people for three days provided me a new view into their world.

Sales people don’t really want to sell. They want to win. And how do they define winning? It is amazingly simple. They win when a prospective customers chooses your product instead of someone else’s. It is that black and white. So here is my question to you.

What do you do to help sales win (i.e., make it easy for prospective customers to choose your product)?

Take a moment and write down a few things that you’ve done recently to help sales close deals. And don’t give me a line like “that is why we have marketing”.

Here are a few questions to jump start you:

• When you build a feature, do you know the business problem you are solving for your customers?
  If you don’t, why are you building the feature? If you don’t know, how can you expect a sales person to sell it? It is easy to use the excuse “product management should be telling me to build stuff that can be sold.” That is weak. I don’t accept this from my managers (or my developers, or my QA, or my designers, or my… well, you get the point). Don’t accept this from yourself or your managers, either.
  
  You have an obligation to understand why you build a product feature. You have a responsibility to develop it in a way that makes it easy to sell. Get close to your customers and find out what problem they really want solved. You then have a clear solution (and story) to equip your sales team with.

• Do you spend time with sales while they are selling?
  This is an area many development leaders shy away from at best, and at worst consider to be beneath them. As long as these folks are working for my competitors, I’m thrilled. My advantage is being on site, hearing objections faced by the sales person, and listening to problems faced by our prospects.
  
  When I return from the visits, I share with my development team so they understand the “why” of building our software. I share my responses to prospect’s questions with the rest of the sales team to make them more effective. I seek out input from my current customers to see if they are also facing these problems. This provides me greater understanding as new features are prioritized and designed. That generally leads to very high customer satisfaction with new features.

• Do you provide information that is helpful to sales?
  As I mentioned above, it is easy to fall into a trap that this is some other group’s responsibility. In general, it is true that product management or product marketing commercializes a product. However, you still can produce powerful sales aids. If you receive the same question from multiple sales people, write an FAQ about the topic and distribute it. If you hear objections from prospective customers in multiple deals, write a response to the objection for sales to use.
  
  Communicate in a manner that a sales person and prospects can understand. You might think it is great that you use Microsoft SQL Server Integration Services to extract, transform, and load data from your OLTP database to your data warehouse as a nightly job running in the background so it consumes non-peak processing resources. That means next to nothing in a sales engagement. What matters is that your product has a high-performance and flexible business intelligence solution.
  
  This isn’t about intelligence – it’s about language and experience. I work in the healthcare IT industry. As one of my nurses once quipped, no one ever called for a software engineer when they were dying.

• Do you ask sales people what you can do to help them?
  I think I will let this question stand on it’s own…

Review your relationship with sales. It's worth it.

Harsh start-ups and smooth landings

I recently participated in an end of release cycle product demonstration. It was a wonderful experience and I was proud of the team’s achievement. It’s a great feature that will make a significant impact to our customers and to our business.

During the product demonstration, I couldn’t help but reflect back on the first several sprint demonstrations. Those were much different. Whole screens were thrown to the scrap pile, basic flows were challenged, and even seemingly simple functionality caused excitement among the stakeholders.

As the sprints went along, the conversations deepened, the team solidified, and the product began to mature. With each sprint, the discussions evolved away from major issues and towards minor suggestions and tweaks. During the last product demonstration, the feedback was positive and only a few cosmetic changes were suggested.

The technical lead remarked that we were doing pretty well if that was all the feedback we received. I had to agree. On my way out of the room, I remarked that we had experienced a “harsh start-up and a smooth landing.” Walking back to my office, I started thinking more about the factors that led to this point in the project.

Here are a few ideas for you to consider:

• Trust
  If a feature isn’t working, is confusing, or just plain wrong, anyone on the team or in the stakeholder community has an obligation to say so. This may appear to be an obvious truth, but it doesn’t always happen.
  
  Someone assumes another will catch it. Someone feels that no one will listen. The list of reasons for remaining silent goes on and on. As a leader, you can create an environment where people will stand up and use their voice. Make it clear that all feedback provided (respectfully) is welcome. People provide feedback if they trust that they will be heard, and that they will not be judged.
  
  In short, this trust is what leads to honesty. You have a vital part in making this happen.
  
  
• My product, your idea
  Our sprint teams welcome input from all sources: customers, internal stakeholders, and each team member. I’ve seen QA folks make design recommendations, customers provide workflow suggestions, and internal groups offer changes to improve service and supportability. The teams absorb the input willingly. They do so because they know it ultimately leads to a better result.
  
  They aren’t interested in whose idea anything is. They are interested in producing a quality product that delights our customers and helps the business. This ego-less attitude has to come from you – their leader.
  
  Praise the team each time they incorporate a suggestion from outside the team. Help them understand their contribution to a culture that promotes others to contribute. Encourage them and reward them when they respond to input from others. Their job is to produce a great product – not pretend to know everything. That often means listening to others.
  
  
• Act on feedback
  Do you want to encourage feedback? Then act on it when you receive it. At our demonstrations, I often hear the team place suggestions (and criticisms) they receive into their sprint backlogs. They then prioritize the feedback accordingly. The person who provided the input knows immediately that they are heard, and that the team and the business are going to treat their input with respect.
  
  Make sure everyone knows that not everything raised will get into the release, or even into the backlog. On the other hand, not everything is ignored. It is critical that each person understand the rationale for why a suggestion does or does not make it.
  
  Equally important is assuring the team that all feedback is regarded equally, regardless of the source. I have been told on more than one occasion that my input will go into the backlog – not immediately addressed just because I’m the VP. And that’s OK. I should have to justify a request just as much as any other stakeholder.
  

In the end, build a culture that honors feedback, regardless of where it originates, and does something with it. You will also likely see the degree of ownership among your stakeholders skyrocket. They will be transformed from talking about “the” product to talking about “our” product.