Navigating: What do you mean, captain?

OK, I can't speak for all industries but I can understand that you'd like to hear a few more concrete things you can do navigate these times. Let me share a few things from my software engineering perspective.

One of the options you could look at would be virtualization of parts of your development environment. An area that often proves to benefit is everything that has to do with testing. For instance if you have physical machines to test your application it might be very time consuming to set it up from scratch. You can speed this up by using an image that you can play back on the test machine. With virtualization you can become even more flexible or faster.

Some solutions allow you to create templates of virtual machines. Examples include a server with a specific database server product or a client machine with a particular browser version. If all it takes to select one each and instantiate it you can significantly speed up testing by reducing the setup time. And on top of that some virtualization products have features that allow automating a large variety of setting up virtual machines. And if you don't need them anymore just throw the VMs away. Just like that!

Another area that is worthwhile exploring for becoming leaner is everything that has to do with documents in particular internal documents. Look at all graphs for instance that require manual updating. Is there a graph that can be replaced by a simpler version or by a graph that is automatically generated and updated? Also, in some cases you may be able to simply some documents by replacing some text by tables.

Tools is yet another one. Are there tools that you can upgrade or add that will help your team to off-load more tasks to the tools? Do you use an out-date version control system? How about your automated testing tool? Automation and simplification are key regardless of whether you look at processes, tools, technology, or others. Can you simplify the design or implementation of your product? Can identify a technology that you use in your product that has outlived its usefulness?

There are plenty of options. Keep your mind and eyes open. Observe. Challenge. Put practices under scrutiny. Do they still make sense? Experiment. In small doses. Try out. Maybe you fail. But chances are that what you try will help you to focus even more on what is important in these difficult times.

And at at the same time you will become even more flexible in terms of how to respond to changes in these uncertain times. It's not the changes that hurt. It is how we respond to them.

I'm sure you got my point and are able to translate this into your industry and your specific situation. In particular in difficult times it pays off to have plenty of options for how to navigate through them!

A Thought About Selecting Tools

Once you are an XYZ partner (replace XYZ with your favorite partner vendor) this means that you should be using all XYZ tools. After all you get them all cheap or even for free. So choosing them must be right!

Wrong! Check what the primary reason is why your company is in business. Is it being an XYZ partner? Or is it delivering good products and services to your customers? I bet that it is the latter.

And if you deliver good products and services to your customers using XYZ technologies or tools might be the right choice. But maybe it's not. If you believe you can choose only from XYZ's product list then chances are that you miss out on the best opportunities to improve what you do and how you work.

For example, XYZ may just have large monolithic applications that require training for users and specialists for configuring and maintaining it. And maybe those large applications that try to be everything to everyone become so flexible that all that flexibility makes it hard to change and quickly adapt your processes to your environment. Do you want your tools to support your processes? Or do you want your tools to dictate your processes?

Bottom line: Don't let you limit yourself by being an XYZ partner thinking that you can use only their tools!

Getting Started

Now you are a new member of this team of smart, experienced, and very talented people. How do you get started?

Sometimes it looks to me that the most difficult part is to make sure that the team starts to shift its mindset. This does not mean at all that everything that the team did in the past or everything they are doing today is wrong. Quite the opposite.

A mindshift helps looking on everything in a new light. For instance it might help to rerun an experiment that failed a few months ago because one of the tools wasn't up to the job. If you have a new version of the tool this time the experiment might have a different outcome.

A mindshift also helps you to move to a different approach while - maybe - continue operating the same. For instance when you are used to larger and more complex projects or tools or designs then it can be quite challenging to move in the other direction. What about smaller and simpler?

A mindshift might also require challenging some of your assumptions. What if you are assuming that you get punished if an experiment fails? Maybe that assumption was correct many years ago and you internalized it so much that you are not even aware of it. What if the assumption is incorrect?

Getting started can be very difficult and sometimes it takes a lot of courage. Yes, it is good to know all those reasons why something cannot be done. In engineer's terminology this is the list of rists. But then: aren't we engineers to to make things work despite other people saying it cannot be done?

So try small experiments, maybe a couple of people for a couple of days. Maybe the experiment fails. No problem. Then you know yet another way that doesn't work and you have learned more about the challenge.

But maybe the experiment is successful. Then you have started to move. Admittedly just a tiny little step but you have moved. And you have learned as well. And maybe after you have moved you can identify the next thing already that is worth trying which was hidden or impossible before your move.

Let's look at a real life example to illustrate my point: Let's assume you have that mixture of unmanaged C++ and .NET code and you want to move all of your code to the .NET world. Then switch on that /clr flag and see what happens. Maybe it is successful and maybe then the code for communicating between the two worlds can go away, and maybe then you start seeing new options for what the next best move can be.

Hiring

Hiring people is important to the success of your team and project. I strongly believe that you cannot deliver great products if you have a low-performing team. I strongly believe that regardless what you want to achieve with your team, it heavily depends on the quality of the people. I'd like to discuss a few of the principles I use to select people for joining my team.

Elite Team

It is almost like a positive, reinforcing cycle. If you have an excellent team, people will learn about it, and then they want to join that team. This leads to a greater pool of people you can select from, which in turn provides you with high quality candidates you can select from.

So in that sense an elite team, thinking, or attitude is acceptable and even desirable I think. The challenge is certainly to avoid coming anywhere near arrogance. But if you are pushing your team all the time to become even better - to outperform themselves, and if you have hired people with good character and attitude than this is a no-brainer anyways.

Hiring Process

It is important to distinguish between trying to assess the quality of a candidate in general, and assessing how the candidate fits with your team. I think you should focus very much on whether a person fits your team. If a candidate is a perfect engineer but isn't a fit for your team, hiring that person will not do any good. Similarly rejecting a candidate doesn't mean that the person is a bad engineer. It merely says that the person wasn't a good fit for your team.

If given the choice of a) a candidate that is perfect as an engineer but has weaknesses on the interpersonal side, and b) a candidate that is a perfect fit regarding interpersonal skills but has some weaknesses on the technical side, I would always go for b).

Part of my hiring process is a programming task. This is a very simple task with about half a dozen stories. Good solutions typically fit on two letter/A4 sized pages including tests. It is amazing how good that filter works. I have seen "senior" engineers claiming to be experts in Java, C#, and C++. But when asked about the differences of generics (Java, C# - different in both cases) and templates in C++, I looked into a face that spoke a clear language: "I have no clue."

Sure that was an extreme case. But still. If a candidate cannot even do a very simple programming task it won't be much better if the task is part of a regular project.

Team Buy In

I believe this is an important aspect as well. When you hire a person always keep in mind who you expect the new person to collaborate with most of the time.

The technique I use is to basically ask two of my team members to run the actual interviews. At the end of the hiring process those two people then can make a recommendation who they believe is the best fit.

This does not take away your responsibility to make the decision. But it allows your team members to be heard and to voice their opinion about the candidate.

Once your team members have voiced their opinion and assuming you follow their advice, you will find that the buy-in of your existing team members with regards to a hiring decision is substantially higher. At the same time you ensure that you don't overlook something. When selecting new development workstations I ask my senior engineers to look at the specs as well. Why would I want to reduce the quality for the hiring process?

Hiring Managers

Admittedly I don't have a lot of experience in this field. Still I believe that the above principles apply to hiring managers as well. Even if you seek advice from your team the final decision is still with you. After all a commercial enterprise is not a democracy.

By not asking your team members for their thoughts about different candidates you basically reduce the buy-in, and potentially you might even overlook an important detail. You are missing an opportunity for building an even stronger team.

Certainly, your department is your "ship". You can run it any way you like. But I believe that with flat hierachies and with self-organizing teams, and given that we are now in the 21st century, and people are more self-directed and teams are more self-organized, it definitely is a good practice and pays off when you involve your team when hiring, including hiring managers. I don't see why the principles that work for engineers shouldn't work for managers as well.

Just my two cents. As I said I don't have a lot of experience so it might well be that I'm overlooking something here.

Setbacks

What do you have to anticipate when you have a large number of new members on your team? This doesn't necessarily mean that the new member are really "new". They might have worked for an extended period (several months) on a different project or product.

One likely consequence is that people may no longer be as familiar with how your team works. Or in the case that they are in your team for the first time, they don't know at all how your team works.

At the beginning of this month quite a few new people joined my team for the next release cycle. They are all good engineers, keen to deliver good quality. Yet, this week it happened that although the continuous build was broken, a few more commits of the code base were made.

This was definitely not their fault, and it also was resolved very quickly. The team leads chose a good way by simply talking to the people and explaining to them why it is important to stop committing more change sets if the build is broken. Apparently some of them came from a background where this was not as much encouraged as it is in my team.

In my view there are more than one lesson to learn from this:

• If there are new people - either from other teams or new hires - you have to expect setbacks, even if you conduct a proper induction to the new team members.
• By working in a co-located team, and by using pair programming as a default, such setbacks do not go unnoticed for very long.
• If you have helped your team to become self-organized, you don't need to step in. The team will take care of such issues themselves. They will find good approaches to resolve such issue immediately.

So, don't be afraid of such setbacks. It pays off to have the courage - one of the agile values - to delegate decisions to the team. They become much more self-sufficient, and setbacks are handled much faster and without your intervention.

I think my team did a great job here. Although they were not "hoping" that something like this would happen, they behaved exactly as expected. They simply helped the new team members to learn and that way to become even better team members.