Management Wisdom

by Scott M. Brylow

I’ve spent a number of years managing technologists, both in technology companies and in companies whose survival depended on technology. My teams have completed small projects, large projects and mission-critical projects. And I’ve homed in on a list of guiding principles that have helped those projects and those teams succeed.

As I began independent consulting for clients, those principles came more clearly into focus and I wrote up my guidelines below. They are divided into four main sections – delivering, communications, hiring/training and strategy. I don’t want to rehash the sorts of things that appear in textbooks and continuing education courses, rather, I’m trying to focus on things I haven’t been taught somewhere else, but that have made a real impact on my ability to work well in an organization.

Of course, I would never claim to be the source of all this knowledge. I've been quite fortunate to work for and with some extremely wise and talented folks. A partial list of them is here .

  • DELIVERING
  • The heart of a job is clearly what you accomplish. To me those accomplishments center around measurable results. The process of delivering work needed by the organization consists of the following:

    1. Requirements definition
    2. Planning and estimating
    3. Doing the work
    4. Tracking the work
    5. Producing a valuable result
    6. Problem Resolution

    1. REQUIREMENTS DEFINITION
    2. Help your organization refine requirements
      Often, requirements are crafted by non-technologists who may have a limited understanding of the difficulty of each task. Your involvement while requirements are built can result in faster delivery of a more targeted set of requirements...

      Map the requirements to implementation-centric language

      No matter how well-trained your project people are, they won't describe things in the terms that the engineers can code to.  So, there's a valuable middle-step in the project process.

    3. PLANNING AND ESTIMATING
    4. All estimates must be bottom up
      [Thanks to Steve Colwell for this insight]
      When technologists report to you, always remember that their job is to know things you don’t – let them exercise their knowledge and skills to provide estimates...

      Estimating is a skill that gets better with practice
      Technology development projects are famous for poor estimation. Encourage your team to estimate work before they begin it. More importantly, close the loop and review the accuracy of those estimates when the work is done...

      Provide context for your estimates

      Estimates quietly embody all sorts of assumptions.  Make those assumptions visible when presenting estimates to your supervisors...

      Build and manage your estimation track record - build trust, not padding
      There's a problem with estimates - they often aren't trusted.   Why is that?...

    5. DOING THE WORK
    6. Build process, preserve data
      [Thanks to Bryan Dunkeld for this insight]
      Companies create an incredible amount of information about their customers, or their manufacturing processes, or their internal performance metrics. And, over time, they run the risk of compartmentalizing this information You can help your firm avoid such business knowledge compartmentalization...

      Build cross-functional teams, build relationships

      More and more projects require a working relationship between your team and folks in other parts of the organization.  This is an opportunity...

    7. TRACKING THE WORK
    8. You can’t fix what you can’t measure
      At the technical level, troubleshooting is preceded by an information gathering, but this approach is often lost at the management level. Work to identify a problem in detail so your fix can be as targeted, and therefore as efficient, as possible...

      For your team, report-writing isn't productive work
      But for you, it is.  How do you manage this dichotomy?...

    9. PRODUCING A RESULT
    10. Templates offer easy ways to aggregate data.
      Use templates for data gathering, process reporting, and in other places where you can get quantitative information. Think of them as automating questions...

      The rest of the organization is your customer
      Your task is to provide the business with the tools it needs to succeed. If they aren’t happy, you shouldn’t be either. That doesn’t mean they are always right...

      Show your deliverable meets the requirements

      [Thanks to Dr. Michael Malin for this insight]
      You should always measure your deliverable against the requirements document.  It's a powerful tool for the shared understanding between your organization and the rest of the company...

    11. PROBLEM RESOLUTION

    12. Fix something once so it doesn’t break again
      Every time you come across a problem, examine the cause, fix the cause, and automate the fix...

      You can make the right decision 80% of the time on 20% of the information.
      You are expected to make sourcing and vendor decisions, product feature decisions, and prioritization decisions in support of business needs. These decisions have long-term impacts...

  • HIRING AND TRAINING
  • You can’t deliver if you don’t have a great team. Getting and keeping that great team is a significant part of a manager's job. And it’s not as hard as it sounds if you keep the following in mind.

    Skilled people want to do the right thing
    Take advantage of this and make it as easy as possible for them to do so...

    Skilled people want to acquire more skills
    Give them that chance, either by varying the tasks they work on, letting them improve how they accomplish those tasks, or getting them explicit external training...

    It’s hard to hire bad people at the technology professional level, you can only hire good people and ask them to do the wrong thing.
    Hiring is hard, there are entire books written about it; I’mnot going to write another here. Many of those books contain useful information to let you find quality people...

  • COMMUNICATIONS
  • Without strong communication, everything is at risk – that includes your team’s understanding of their priorities and goals, your bosses’ understanding of your team’s performance and direction, and all your relationships with your peers. While separate from the “deliverable” items above, communications is something to attend to every day. Make sure you have personal processes in place to handle every contact that comes across your desk every day. Promise yourself and others 24 hour contact turnaround. The items below fit easily into the following categories:

    1. Message passing up and down
    2. Problem resolution
    3. Meetings
    4. Documentation

    1. MESSAGES, UP AND DOWN
    2. Management is primarily about communication and risk-mitigation
      You are getting paid for your management skills. Your team is getting paid for their technical skills…

      No surprises in either direction
      [Thanks to Joshua Newman for this insight]
      Given the above (communication and risk-mitigation) this naturally follows – you should do everything you can to mitigate risks and communicate…

      The further up you are, the less you know
      [Thanks to Maclen Marvit for this insight]
      Breadth is more relevant than depth to a manager. You need a shallow understanding of a wide range of things and the ability to go and get the right answer…

      Your job is to filter communications in both directions
      Always work to keep your supervisors in the best light in the eyes of your team. Always trumpet your team’s success to upper management. Do those two things delicately rather than blindly…

    3. PROBLEM RESOLUTION
    4. Make personal issues process issues
      Someone’s perceived failure to do what you want could be personally frustrating, but rather than operate in that personal realm, it is more productive to try to frame that non-performance in terms of a process…

      Take responsibility for communication breakdowns
      Always assume that communications problems are your fault. It may not be strictly true, but it's a useful way to frame the problem…

    5. MEETINGS
    6. Less meetings are better
      Corollary – shorter meetings are better
      Meeting time should be short, follow a tight agenda, and have a clear goal in mind. General status meetings rarely, if ever, meet these criteria…

      Cross functional meetings help build cross functional teams
      Taking people from different parts of the organization and throwing them in a recurring meeting can build bridges across those teams…

      Stand up meetings focus the attention and stay short
      [Thanks to Ed Danielson for this insight]
      Use them to emphasize the importance of moving quickly when you are having problems or to show the operational nature of the meeting...

    7. DOCUMENTATION
    8. Be willing to publish process documentation internally before it is complete
      My experience with process documentation is that iterative development is wise here (though perhaps not as true with product documentation)…

  • STRATEGY
  • How can it be that the highly-touted “strategy” section is down here at the bottom? My belief is that “strategy” is currently an overused term in technology organizations. Technology strategy means making technology decisions and building a technology platform that allow you to adapt to changes in business strategy. All the things we technology managers do to support the current business strategies are merely technology tactics . So, what do I know about technology strategies and technology tactics?  And when is it appropriate to talk about technology strategy??

    A roadmap is critical
    In my experience, people treat strategic initiatives somewhat less formally in terms of tracking effort and measuring deliverables…

    Serving business needs is paramount
    Here’s where we run into distinctions between technology strategy and technology tactics…

    A framework for evaluating results is necessary
    This is true in all cases, but especially in the case where business strategy is affected by the results of research projects…

    Sunk cost fallacies are dangerous
    It all boils down to setting expectations for what your research projects should produce and when...