What is the role of a manager?

Opinions vary on a manager's role from writing code to ordering dinner. I tend to like my managers to be technically trained and competent individuals who have learned they can be more effective helping many people succeed. I have talked about what makes a good manager in other posts but what should they actually do in the organization? Here are the basics:

• Planning
• Hiring
• Employee development
• Execution

Managers help their bosses and their employees plan. This includes budgets, resource capacity planning for projects, schedules, etc. Expect that this is an ongoing task and will take a good percentage of time. In a fast-paced industry things change quickly from customer requirements to found opportunities. Managers must learn to hone their accuracy and deliver estimates quickly.

Once a budget is set, the most important thing a manager can do is hire. Without people they cannot accomplish the tasks at hand. This must be a concerted effort that managers spend time each day doing. From screening candidates to shepherding the process to setting expectations of interviewers and approvers. This can be daunting but is a cornerstone to any company's success.

People development is often overlooked. We cannot expect that all people who come to work for us were born with all the skills and knowledge they need. Nor can we assume they acquired the skills or knowledge in school or previous employment. Employees need both technical and soft skills. There may be times when you can find a class for an employee to take to build skills but managers should be capable and interested in direct mentoring both technical and soft skills.

Finally we get to execution. Execution will dictate company success. All of the other items discussed above are necessary but not sufficient to execute well. In addition, managers must monitor schedules, manage dependencies and troubleshoot issues. This is the day to day management of a team developing a project. You must not lose sight of this activity while doing planning for the next big thing. Managers should represent and be held accountable for his or her team's deliverables. Deliver with quality. Deliver ontime.

With enough managers capable of the above the tasks, your company can achieve its goals and success!

More later ...

What is the role of an architect in software development?

Everyone has to do architecture work to develop and maintain good software products. How do architects fit into the process? What should their responsibilities be for architecting features or products? How much responsibility do they have around product direction? What impact should they have with regards to development processes?

As with many roles, you are best served by defining clear boundaries around what architects should do. It is easy to imagine turf wars between architects and a number of other constituencies including developers, managers and product managers.

Here are the three basic areas that architects should own:

• Architectural roadmaps
• Architectural specifications
• Developer processes and best practices

The architectural roadmap is the first place architects feed into the process. These roadmaps should feed into product management just like other requirements including those from customers, sales, standards, competition, etc. The format can easily follow similar strategic documents I have proposed in the past:

• Taxonomy - what is important in a particular areas
• Report Card - how the product does in that area
• Today picture - a visual representation of what the area looks like today
• Tomorrow picture - a visual representation of what the area could look like
• Projects/Tasks - a list of what must be done to actualize the tomorrow picture

The areas might include discreet technologies like storage or networking or they may reflect attributes like quality, usability or performance. The architects should develop roadmaps for each area that constitutes a value proposition for the customer.

The second place architectural oversight is necessary is around specifications. This process should occur after requirements are available from product management but before engineers develop design specifications and schedules. The architects should have unique insight into the overall product and develop these specifications as a leg-up for engineering.

Architectural specifications should include the following:

• Refined requirements - embellishing product management requirements based on the architects broader and more detailed view of the technology and product.
• Investigation items - these should be resolved before a specification or schedule are approved
• Architectural requirements - these must be addressed in any design or development
• Excluded items - these should not be included in the project

This makes the architects the bridge between product management and engineering and provides direction and guidance instead of a blank sheet of paper for engineering. The result should be more consistent products that meet broader goals including interface integrity, performance, quality, etc.

Finally the last place the architects should play a role is in the specification and oversight of development processes. This includes:

• Developing a design/functional specification template and process
• Developing the guidelines and process for code reviews
• Specifying coding conventions and tool selection

The processes should have oversight from the architects. For example, they should get to approve who the reviewers should be for code reviews. Do not mistake this item with saying that the architects must do all the specifications or reviews. They should delegate but retain oversight and they should be accountable. If architects end up doing all of the detailed pieces, developers will resent them and you will not make efficient use of both the architect's and developer's skills.

All of the above items could be distributed throughout an organization but they are usually assigned to senior members of the team and often designated as architects. The important thing is that these tasks must get done and you should make it clear who is responsible for getting them done.

Make your architects more successful and your team will be more successful.

More later ...

Planning

People ask me about Agile and other project planning methods in high tech today. What I tell them is that all tools can be used well or poorly. It takes leadership, forethought, common sense and perseverance to plan and follow through on a project.

Many managers do incomplete jobs at planning, or they do not manage the plan once it is developed, or they do not handle change appropriately. Each of these mistakes will affect predictability. I have seen some organizations that embrace some of these techniques as a facade for "it will get done when it gets done". The problem is that your CFO, VP of Sales and customers cannot plan appropriately in that kind of environment. Your company needs predictability in order to succeed.

I am a lot less interested in the form you use to plan than the functionality. All of these techniques can be applied using almost any method. Here are some basics:

• Do not commit to a date until you have preliminary specifications and detailed schedules
• Make sure every stakeholder physically signs off at each phase
• Adopt a train model
• Don't make top-down dates
• Complex projects require very detailed planning that will change
• Manage each slip with urgency and importance
• Deal with major changes as if you were starting anew

I have talked many times about the proposal and definition phases of a project. You cannot have predictability without specifications. Those specifications must be good enough to ensure you hare heading in the correct architectural and product direction. They must also be good enough to create schedules. The schedules must prove that you can make the target date. You must work with the information you have at the time and understand that it will change. The schedules should be manageable (< 2 week tasks, measurable deliverables, etc.).

Don't assume that verbal or incidental communication is enough to get buy-in from your company. Get a signoff sheet for each phase in writing. Make sure development, QA, docs, architects, sales(customers), support, and the CEO are all in the loop. It is awful to find out after you have spent money on developing something that you have done the wrong thing.

Feature driven releases often slip. If a major feature slips and the release slips, then there is pressure to add more features since it will be a while until the next release. Adding late features can cause more integration work and potentially more slip or worse yet cause quality problems. Separate features out from releases. Make releases time based with a shorter cycle (3 months). With a time based release, the features that are ready can go out. Big features can be developed independently. You can respond to customer needs more quickly. The train model requires adequate automated testing to be successful in order to reduce the overhead of more frequent releases.

Top down dates don't work. Schedules must be bottoms up. Managers must help there teams make aggressive but accomplishable schedules. Managers must help make trade-offs around function, quality and resources and have substantive business discussion to achieve the right balance. Don't commit until everyone on your team can look you in the eye and commit. This is a pay-me-now or pay-me-later issue. It is more than a burn-out issue. It is again about predictability.

Complex projects need detailed schedules. Even if they go out two years. Schedule re-scheduling events for long projects. If you use Agile, you can translate detailed schedules into sprints but you still need the homework upfront. You need the exercises to get predictability. The schedule is really a step-by-step design. It makes your developers think. It allows your team to identify many dependencies and resource issues upfront. It will change -- get over it. There is no free lunch. You cannot have predictability with coarse grain tasks. You cannot have predictability without having your best guess at the details upfront.

You need to manage the plan. Most slips start from day one of the schedule. Require your team to have at most two tasks open per person at one time as they accumulate risk (this may require scaffolding). Require that each slip have a mitigation plan on a weekly basis. Do not shove all delays into a bucket to be dealt with later. Your team needs to adjust quickly to issues.

Finally, if you have major changes including features additions or architectural surprises, you need to go back into a planning phase. Never assume you can just add it on. Do the resource planning, specifications and schedules. Do new signoffs. Anything less will affect predictability and cause slips.

We all face these issues. True leadership in planning is the foundation for success for your team.

More later ...

What are good goals for testing?

Sadly, software testing has not become a prestigious endeavor in our industry. In ASIC design, for example, the test verification folks often are paid the most and lead the teams. In software, test development and test execution are often looked at as stepping stones to product development. As a result, test development has developed a stigma and is often done as an afterthought and often not pursued by the best engineers.

Without reasonable tests and test infrastructure, your company will spend a lot of time and effort doing manual testing at each patch or release. You may not be able to respond to customer requirements in a competitive fashion. The worst result may be inflicting poor software on your customers and having them find your bugs while you lose your reputation.

So how can you set good goals and get better results in your testing effort? Here are the basics:

• Make sure everyone feels responsible for quality
• Define detailed acceptance criteria that drives what you test
• Invest in infrastructure for testing
• Drive toward specific goals around automation and responsiveness

I have talked about many of these issues both in the book and in other blogs but I will summarize them here as a reminder.

Everyone needs to feel responsible for quality. From the developer who should produce automated exhaustive functional unit tests to the project or release owner who should drive quality across many functional areas, everyone should feel responsible. Break down the organizational walls. Treat quality like performance or reliability and bring to bear the resources you need to make it happen. Don't differentiate between a development specification and a test specification -- make them one document. Send a message that there is only one thing and that is a quality product for your customers. Send a message that there is only one team and everyone must work together to achieve quality.

Don't let acceptance of a project or product only be that it contains no critical bugs. That measure is a second order measure. Define the parametrics for the product around performance, durability, interoperability, compatibility, usability, etc.. Decide on those things together with all of your developers and product management. Use those criteria along with exhaustive functional unit tests to drive the test portion of your specifications. Make sure you identify real customer scenarios as a basis for the tests. Finally, measure, measure, measure the results in both your schedule as the tests are completed and in your integration as more of the tests are deployed. Do not hide these details behind test points. Expose them in highly visible presentations. Make sure everyone can see what is important to the team with respect to determining progress and whether the project or product is done.

I hate the word framework. It is used to denote a lot of things and does not communicate what work is actually being done. Testing frameworks fall into this grouping for me. So what infrastructure needs to be in place for people to actually develop automated tests? Here is a list of the basics:

• Tools to setup and knockdown a test. These may include tools that can reboot or reinitialize test platforms and/or test drivers automatically. They may include setting up a configuration or data set. Clearly how fast they work is a factor.
• A programmatic interface to the test platform. This may be through a CLI, scripting language or API. It must work remotely. It must control as much of the product as possible in order to test as much as possible. Avoid doing this through the GUI as test vehicles that go through the GUI are often hard to maintain.
• A standard output format. Define what you need for summary and detailed information. If every test produces different output formats or worse undecipherable output formats, you will spend an enormous effort in trying to figure out what is working and what is not.

Obviously there are always more items that you may need for a particular product or environment but your list should always include the items listed above.

The last thing you should do is set goals around automation and responsiveness. How much effort should it take to test a patch or a release? How much elapsed time should it take to test a patch or a release? By its nature, the last question will affect the answer to the first question (i.e. with a limited amounted of time you will need to automate more and it will reduce the effort). So here are my rules of thumb for elapsed time:

• For a patch you need to be able to broadly but not deeply test your whole product within 12 hours.
• For a release you need to be able to test your whole product broadly and deeply within 7 days (excluding duration tests for obvious reasons).

The patch level test is often also used on nightly builds during a development cycle.

Obviously your goals should be to reduce the effort for both kinds of test cycles as low as possible. However, there will always be a manual component to verify that GUIs look right.

If you follow the guidelines above you can set better goals around testing and achieve better results for your team and your company.

More later ...

Compartmentalization

You and your team must do the best job they can. You cannot do everyone else's job. If everyone did a good job at their own tasks, the company would succeed. So what do you if someone or some team in the company is not doing what needs to be done?

Obviously you must try and determine how big an issue it is for the company. If the company will absolutely fail then speak up loudly. Otherwise it enters an interesting realm. Do you let mistakes happen? Do you try to do everything? How do you provide input? How far do you go?

I will admit that I have parted ways with companies over this very issue. I have a strong belief in doing my job well and have my team do its job well. I believe I can provide input to other teams but they have to make their own way. I do not believe I or my team could or should try to do other team's jobs. Sometimes this will result in failures (again temper this by the scope of the item) and it is ok. Sometimes failures result in fixing problems at a more fundamental level.

One metaphor is baseball. If some player is doing a poor job, another player cannot do their job because that will cause failure in their position. While some player's jobs overlap, it would be hard and confusing and ultimately cause failure. The manager must replace or train poor players to be effective and successful. Companies are the same way. Each team must do their job. A manager must train or replace unsuccessful people and teams. Do not expect another team to drive or cover for a poor performing team and not impact the original team's responsibilities.

This comes down to clear responsibilities and accountability. Make it clear who owns what tasks. Hold them accountable. Do not reward others for overrunning a team that is not successful without direction to do so. But make sure there are opportunities for anyone to bring issues to light on anything and create mechanisms to follow up on issues.

Make sure there is a single owner for cross-group projects. Hold them accountable.

If everyone is successful on their projects, your company will be successful.

More later ...

How late should you allow changes in a release?

This entry is about the very end of a release. I have talked about the whole end-game in a previous posting but this period warrants more discussion. There are always more bugs to fix. Sometimes this pressure comes from engineering trying to perfect a release and sometimes from product management trying to help out one more customers or avoid a service call. Either way I suggest you avoid a lot of changes down the end of a release.

There should always be a quiet period before a release where only bugs that would stop shipment and cause an immediate patch of a production release should get fixed. Clearly the length of this period will vary with the size of release or the maturity of a company. But the period should not be less time than a full run of testing (which should be set to take 7 or less days).

In this period, any bugfix is as likely to cause more problems as fix problems. People like to minimize the impact of changes in this period but my experience does not support that position. I have seen slips due to innocuous changes.

If you have not met your bug goals or you have not completed testing do not enter this period because you will need to fix bugs that are not appropriate for this period. Do not assume you can fix a lot of bugs and keep the release stable.

So what can you do to manage this period:

• Show leadership
• Plan a patch release shortly after your release as a vehicle to handle critical non-showstopper bugs.
• Get involved in the bug reviews yourself
• Do not start new testing that has not been performed before in the cycle

Managing this period well will improve your company's and group's predictability which will in turn enhance your chances for success.

More later ...

How can you train managers on an ongoing basis?

You may ask your staff to accomplish a task like schedules, replan, review, or budgets and it does not get done. They make a commitment for a new date and it comes and goes without success. What should you do? Do you admonish them? Do you fire them? Do you train them? This entry concerns the last question.

Clearly it is unacceptable for your employees to miss delivery dates. Make sure they know they are accountable have to inform you early about potential misses. But you need to look at the root cause. Some employees may not have competence and you should manage them appropriately but others just have not been trained.

We know that most managers in engineering have not had management training. Part of your job as a manager is to train them. Take the time and have patience. Do not be surprised if employees with big titles are missing some key skills. Train them and they will not only be more productive but they will learn how to train their own staffs.

Here are the basics for a missed task:

• Set a new deadline for a task.
• Notify your employee that if they miss the new date, then you will work on it together.
• If they miss the task, call a meeting and allocate enough time to complete the task together.

I often use the term "lock the doors until it is done". Then you have to complete the task together. Like any other learning situation you have to be careful to not do the work yourself but you need to be in the room and guide the task until completion.

Once employees learn about this method, you can tell them they can ask for this help before they miss a deadline. Be open and generous in the process. If they feel like they are being punished, you may not get what you want out of the process.

You certainly should explore training classes for employees as a proactive tactic to minimize some of the need for this technique but you should still expect to do this kind of training.

Create a learning atmosphere and your team will learn how to succeed.

More later ...

Follow up!

This is common sense to some and not to others. In any interaction you have with your team, peers, boss and customers, you must follow up. This is one of the great differentiators between junior and senior managers and between those you can depend on for results and those you cannot.

Many times people avoid following up because they have incomplete results. Get comfortable with intermediate status. Inform people often. If you get asked about an action, then you should probably have considered providing status or information without having had to be asked.

Other times people avoid following up because of conflict avoidance. Maybe you didn't meet expectations or you do not see a way to close an action item or you think the item is not worth working on. I suggest you address it before it becomes an issue. Reset expectations, ask for help, or discuss the usefulness but don't let it go unaddressed.

Teach your employees about what you expect. Keep an action item list from your meetings with meaningful deliverables and due dates. Tell your folks how frequently you expect status on items. Follow through with them. Mentor them. Hold them accountable.

Similarly, be proactive with your own list of items you must follow up on. Actually keep a list and manage it. In larger organizations, use a program manager to help manage it. Strive to never have anyone have to ask you where things are at on an item.

Note that you may have to learn how to interact with various people. Even though others may not be explicit about how frequently they want status, you need to adapt. There are lots of ways to communicate including email, websites, phone calls, and dropping by in person. Find out what works best and is appropriate for colleagues versus bosses, etc.

If you follow up you will become more valuable to your company and reduce stress in your job. If you can help your team to learn how to follow up you will surely make them and your company more successful.

More later ...