How to be perfect (hint: just re-define 'perfect')

I was assigned to work closely with a very capable technical leader. I looked forward to my first meeting with him when I would have the chance to go through my usual on-boarding process. That normally consists of finding out what a new team member's goals and ambitions are, where they think they fit in to the organization and what they want from me as their manager. Sometimes these discussions are simple and sometimes they can be very complex, dragging out over a period of weeks. Regardless, they are always useful and productive.

This particular leader was clearly seen by others in the department and by the entire regional office as a respected expert. He had experience to match that respect; he knew our products and industry well. But in our ramp-up discussions, he raised the issue of emerging as a full-fledged personnel manager. He was tired of his limited technical role and wanted more. He was tired of never having the last word in broad meetings where technical issues were just part of the problem.

We discussed the ins-and-outs of the management role and my perception of what might limit his success. He pledged to work on those areas and our discussions continued. At first he continued to do a great job as a technical lead, exceeding my expectations for his ability to adapt toward better interpersonal communication and teamwork.

When we began to discuss his first management role, he embraced it enthusiastically. Everything seemed aligned so we formed a small team for him and kicked off a project. Nearly immediately, however, things started to unravel. Two people from his team approached me to escalate concerns about their assignments and the plan their new leader had set out for them. The new leader himself began working extreme hours and still could not keep up. He also began complaining about some parts of the management role which he felt were beneath his skills. He requested that a project manager be assigned to his team so he could delegate work to them.

My style is to be very direct with management issues but he was imploding faster than I could schedule feedback discussions. The situation was caustic as he blamed me for the issues and wanted more time, but I needed to take swift action in order to avert an employee and project disaster. He proposed a solution that brought the situation into perspective. Basically, he felt that his responsibility for non-technical issues was a bad use of his time, but that as technical leader, he had previously not had enough responsibility. So I should make him the leader over the entire department, with delegate resources to handle the areas where he fell short personally. In essence, if the role were perfect for him, he would be perfect for the role.

Faced with a tough technical problem, he would never have tried to re-define the constraints just to make his life easier. But that's exactly what he was doing in his first leadership role. It is meaningless to say that you perform well in a role so long as it is a role that you perform well. The whole point of the leader is to bring the team together, filling-in the gaps between them; that is not possible when the leader's role is stiffly defined in a hierarchical dominant fashion for others to align around.

Thanks for reading this Management Use Case. I'm the co-author of a new book on software development leadership entitled You.next() that features dozens of other use cases for leadership. Please see more at www.youdotnext.com.

What Not to Do with a Video Cable

I had an employee once who was setting up a test system for an important project. This person was not a junior engineer; in fact, the person was recommended highly and transferred temporarily at great expense to my group because of reported effectiveness.

After a couple of days of setup, I looked in on the progress and found out that there had been a snag. Additional people would be needed and it could be resolved in a day or two. I approved and made the assignments so it could get done.

At the end of that first week, there was one specific issue still outstanding. Now keep in mind that all of this is in the setup for the project, not in the project itself. The one issue outstanding would require us to ship hardware across continents to fix. I recommended a few things to try while the hardware shipment was underway.

Another week went by and the emergency shipment of hardware arrived just in time for a progress review. Still no-go; the system was not working. At this point, nothing was beyond my suspicion and frankly, I was mad. I was having to report that we could not even start this project and all the resources I had applied were not helping.

So I visited the lab. I poked around the system and within 3 minutes (it was just that long -I wish I were exaggerating) I discovered that they had a video cable where a serial cable should be. It was a DB9 cable for those who care; the old-school monochrome CRT's had a DB9 connector and so did the second version of PC serial ports. The connectors were the same but the cables were not.

Another two minutes to find a decent serial cable and test it... everything worked. I went from mad to nuts... why had nobody realized it was the wrong cable? Why had nobody tried a different cable just for the hell of it while they waited a week for new hardware? Why had all of my resources yielded nothing? Why do I have to do everything myself?

I behaved badly. I was frustrated, and it showed. This would have been a great opportunity to teach people, regardless of seniority, about how to diagnose this kind of problem. How to separate hardware from software issues. How to troubleshoot a big system. All sorts of things could have been taught. But I taught them something different.

By getting angry, I taught them to avoid telling me what was really happening in their work. I taught them to avoid any opportunity for me to enter their workspace. I taught them to avoid getting on another project where I might judge their ability to do exactly what I would do instead of measuring their ability to show a balanced blend of many different skills including teamwork, client focus and camaraderie.

I should have been in the lab more - I might have even spotted the problem a full two weeks earlier. I should have talked more in-depth about the problem and asked the right leading questions to exhaust silly things like bad cables. I should have celebrated finding the solution rather than getting angry when the trouble was over.

The funny thing is that no mater who I blamed for the problem, it was my responsibility. I was entrusted with the people and the goals. If I managed well or poorly, made good or bad things happen, it was all mine. So I might tell myself that the people involved should have known better and that other people would not have failed me but the fact is I picked them and made the assignment. I gave them two weeks of rope and carte-blanche resources. In retrospect, I really had no idea what they were doing - which means that, as the manager, I had no idea what I was doing.

Thanks for reading this Management Use Case. I'm the co-author of a new book on software development leadership entitled You.next() that features dozzens of other use cases for leadership. Please see more at www.youdotnext.com.

Typical

Software, while wildly successful as a commercial product, is an incredibly young discipline. The tools of the trade are just barely starting to take shape when compared to many other disciplines in medicine, engineering, law, or government. Software has drawn mathematicians and engineers, tinkerers (with their own special name in software, hackers)—even artists. The work itself is a combination of these skills—art and engineering in software design and architecture; detective work, forensics and problem solving in debugging; modules assembled like so many bricks and sticks of a builder. Any one of these fields of work has a tradition of established hierarchy and career path, via fellowships or tenure in academics, apprenticeships in the trades or hierarchical promotion in engineering.

Here is a relatively standard perspective toward “management” from an evolving software professional:

• Early career: I don’t know what is good or bad about my managers.
• Intermediate: I know what I like and what I don’t like, but I am not ready to try to do better than the professional managers around me.
• Midcareer: I could manage better if “they” would put me in charge.
• Every day after that: I should have tried to be in charge, but I’m too busy.
  

It is important to distinguish the types of management and make sure the one you are seeking is the one you really want. If you are given a new challenge, determine which role is actually given to you and whether that is a stopping place, a dead end, or the right track:

Working Lead
· Performs the same function as everyone else on the team, with some time allotted to leadership functions
· Handles escalations from within the team and mentors team members
· Responsible for schedule commitments made by everyone on the team

Technical Lead
· Responsible for directing technical decisions for everyone on the team
· Go-to person during design and requirements crises

Manager
· People “report to” you for formal human resources issues (compensation, promotion, etc.)
· Review performance of team members
· Interview new team members
· Report to superiors on entire team’s performance against goals and budgets

The manager’s role is to serve the team by making sure that their needs are met, which includes providing a steady stream of well-formulated tasks, suitable to the skills and experience level of the recipient and prioritized by the business. The job is a continuous stream of decisions and communication that can be intensely exhausting at first, especially if done well. The business pressure comes in the form of large projects, which are often ambiguously defined. The manager’s role is to divide and conquer. How he or she chooses to do this will mean the difference between success and failure.

Thanks for reading this Management Use Case. I'm the co-author of a new book on software development leadership entitled You.next() that features dozzens of other use cases for leadership. Please see more at www.youdotnext.com.

Leadership at a Startup

Every software start-up is truly a unique enterprise. Nowhere else can so many people create value with nothing but their own potential and a small amount of capital (generally, for pizza and computers). Of course, it’s also very easy to lose the value before it grows, as when you run out of pizza money before anyone likes what you’ve done. But the point of this is that start-up companies are usually a “non-management” environment. It’s not a matter of intense management or lax management; it’s loosely coordinated management anarchy:

• If there is still money, you work doing whatever you do that adds value.
  
• If there is no money, not a lot changes except that you have to decide if you’re willing to work for nothing for a while.

The idea is that if it all works out eventually, there will be money to create organizations and so on. Because you were there early, you’ll skip all the levels of bureaucracy at Dilbert®-style companies that already got old. Maybe…

Working at a software start-up is like concentrating time. You can focus on exactly what you are best at doing, which is how we experienced it. (Both authors went through it at different companies on different continents but the experience was the same!) Most software professionals have experienced some form of crunch time—the variable seems to be only how long it lasted. In a relatively short period of time, you get good with the tools at hand, translating school knowledge into tech magic. When the bag of tricks runs out but there’s still more intensity needed, you learn to research and expand yourself in real time. You find the state of the art for your specific task and immerse yourself in it. Feeling powerful and sharp, you take on bigger and bigger jobs, shunning the suggestion that someone else should be brought in to help, assuming that’s even possible. A few late nights and some weekends is all you need to stay on schedule. You are now a hero—irreplaceable, self-sacrificing, revered, and respected.

Before you even realize it, though, you are burning out. Skills are evolving, but technology is mutating right under your nose and you can’t change fast enough. There are no more hours in the day that you can work, and you are already as good as it gets with the tools at hand. The light at the end of the tunnel gets further away, and you need help! One answer, a very good one in fact, is for you to find a way to scale your abilities. Learn to achieve more through management.

Thanks for reading this Management Use Case. I'm the co-author of a new book on software development leadership entitled You.next() that features dozzens of other use cases for leadership. Please see more at www.youdotnext.com.

Runaway Pattern

There’s a runaway pattern of holding strong software developers in key technical positions while befuddled managers do nearly everything else incorrectly. It’s not quite that bad, but Dilbert® cartoons would not be popular if something were not fundamentally wrong in the software development industry. You can be part of the solution, but you have to decide to make your move.

The capabilities of a software manager, broadly, are two. First is functional or technical leadership ability within a domain of knowledge related to the work that is being managed. The second is the will to lead people. These are complementary abilities—they support and build on each other as your abilities grow. Still, for most people, one or the other of these will be stronger, and that one will generally set the tone of your management career. The simplest way to see this is the ultimate evolution of these capabilities into the chief technology officer (functional leader over technology direction) and chief operations officer (usually responsible for most of the people who execute day-to-day business). Both of these chief roles require a strong capability to lead, but they arise as distinct abilities and strengths in a career.

As a manager, you can outperform many others who use the concept of evolving design incorrectly. They do not understand the technology well enough to evaluate the feasibility of a solution to an obstacle. Without the power of technical aptitude and experience, they direct their teams to get started, hoping everything will work out. These managers passionately direct their teams toward goals that will never be achieved, destroying confidence and value until the effort is abandoned. Technical competence, on the other hand, allows you to know what should be possible (and the caveats to express it properly), and what is impossible no matter how well things go.

Thanks for reading this Management Use Case. I'm the co-author of a new book on software development leadership entitled You.next() that features dozzens of other use cases for leadership. Please see more at www.youdotnext.com.

Cach and Cachet

The highest paid people in most companies are in management. The rewards for managers arrive slowly, but they pile on for years. The work is very hard, complicated, and frustrating! The stakes are high: you will be rewarded not only by those above you, who appreciate your achievements and feel comfortable giving you bigger tasks, but also by your team, who feel they owe you much of their success because of the opportunities you created for them.

Even if your cash compensation is sufficient, you may feel unappreciated at work when your pay raises are lower than you believe they should be. For technical people, compensation clearly is linked to ability but also to market rates for the ability in question—when more people are available to do the work, companies can afford to pay less. The converse, of course, is also true. For management functions, the environment is more dynamic. Great managers are highly valued and paid with “retention” packages that are intended to keep their focus away from any new job opportunities. But the path from being a developer to a member of senior management is a long and uncertain one.

A second important factor related to cash is not only your ambition but that of your family and other dependents. Cash is the dominant term in the perceived rewards that you take home. You will feel disrespected and unappreciated if your role is unable to provide sufficient cash to meet their needs, which will ultimately challenge you to consider your role and even your choice of employers. If you are honest with yourself about these needs, then your career ambitions will align properly with the roles you seek and the kind of company where you are engaged.

Thanks for reading this Management Use Case. I'm the co-author of a new book on software development leadership entitled You.next() that features dozzens of other use cases for leadership. Please see more at www.youdotnext.com.

The Box

You can think of the entire product development process, from concept to final testing and documentation, as a black box. The box takes in requirements and produces, via engineering and scientific principles, a product. This box can operate more or less efficiently and more or less reliably. The black box can create a lot of adverse by-products (angry beta users, burnt-out development teams) or useful by-products (well-honed teams, beta customer references, mature processes, and reusable platforms). But these are secondary results and not the true purpose for which the box was put to work.

Every emerging manager works inside the box at first, handling specific tasks and paying little attention to anyone else’s work. But curiosity or ambition or sheer luck occasionally turns the budding manager’s focus to other parts of the environment where unusual things are happening.

Other individuals are doing their own work—not all at the same pace or with the same skill. Other teams are organized differently, and these differences appear to impact how people feel and how well they do their jobs. At first, these are simply mental notes or casual observations. The patterns that define the effectiveness of the box seem to be random and chaotic; as such, they are uninteresting phenomena because they cannot be controlled by technical efforts.
Still, something is following a pattern. Everyone who works for a certain manager seems to be happier than everyone else. Certain products don’t seem to have as many problems as others. People on some teams are well known in the company, while no one has even heard of other teams. Like with any system, more information is needed before the pattern can be discovered. Under tight deadlines and peer pressure to master new technology, the discovery of the management pattern remains a distant curiosity. For some, the need to master the pattern never matures into action. For others, there’s a shortcut: go outside the box.

Thanks for reading this Management Use Case. I'm the co-author of a new book on software development leadership entitled You.next() that features dozzens of other use cases for leadership. Please see more at www.youdotnext.com.

Leadership is a complex problem

Learn the business of your product. How does it fit into the operations of its ultimate users? Is it a productivity tool or a part of their sellable product? Does it automate a process between people or a protocol between equipment? These are important questions ultimately related to how your product can be priced and sold. In turn these core issues are contributors to how the product should evolve over time. When you understand what it does rather than how it works, you have taken a huge leap past many of your peers.

Business knowledge distinguishes the leader from others on the team. Understand how the product makes money. Understand how it is used. Know and communicate with customers when called upon. Have a good relationship with the representatives from every function that is required to release your product (QA, documentation, marketing, etc.). Think about what might have been missed in the project plan and mitigate risks proactively. Engage with other teams that you depend on to ensure that they are on track. Drive specification reviews between teams and customers. Learn the competition – what are the people like you at other companies thinking, and can you think smarter? Listen to everyone who has something at stake. It’s a long list, but if you are truly emerging as a manager, you will one day complete them all, and a hundred others, instinctively.

It is important for you to know the competition that works against your team or your company. Learn how your company profits from the product. Does it cut internal costs? Is it a big source of recurring maintenance revenue? Is it a loss leader that guarantees a long stream of customization revenue? If you are not selling a product but instead bill your time by the day or by the hour as a consultant to your clients, what is the core competency of your company that most interests those clients? All of these are important topics that will help you think differently about technical problems.

You have to solve the business of the problem, not just the technology of it. It may be necessary to do any of the following things even while in the process of doing what you have traditionally considered to be your job:

• Determine how to solve a whole category of problems similar to the ones currently on your plate. If you get good at it (“gain a competency” in commercial parlance) then your company can rely on a steady stream of profits.
• Determine how to lower the cost of solving the problem or deploying the solution. A cheaper solution that is just as good will always be more appealing. As a bonus, it is also generally true that simplicity is beneficial both for the cost and the elegance of your team’s work.
• Determine how to make solutions more predictable from the perspective of the users. Would you ride in an airplane that has never been tested? Neither would your customers; the cost of ensuring stability will more than pay off in increased value.

Thanks for reading this Management Use Case. I'm the co-author of a new book on software development leadership entitled You.next() that features dozzens of other use cases for leadership. Please see more at www.youdotnext.com.

Cut yourself off from your code

A classic pitfall that traps many developers is a high level of ownership and dominion over source code modules. The code has a personal, essential quality for these developers, as if it were their own form of artistic expression. University training teaches this artistic level of elegance in algorithm design, and after all, many great developers have been writing programs since they were bringing home art projects for Mom and Dad. Occasionally, the three-way love affair (developer, source code, company) works well, even for a long time.

For the emerging manager, personal attachment to source code is a mistake. Thanks to Von Neumann, software is just that—soft. It has to change with requirements and time. Anyone’s code can be learned and continued by someone else. In fact, source code needs to be more readable by a person than by any machine. Sure, a compiler has to parse the code, but a person should be able to understand it. Every programming student hears that comments are good and style is important, but few are taught that their career depends on it.

Source code should be documented in a way that anyone coming along at any time could understand what it does and why. The brilliance of any great program lies in the mind of its creator; the software itself is just a reflection of that brilliance. Buried under the same evolving modules for years, it is natural for some developers to believe that their creation (source code) is a part of themselves. As such, suggestions for improvement are rejected and the very idea of a code review feels like a violation of personal rights. Unfortunately, their careers are as frozen in time as the code they worship.

You may be thinking that the idea of working to become independent of your code is contradictory to the notion of being a subject matter expert or functional leader. There is some overlap between knowledge of a specific code base and its business value or technical domain. But a true functional leader has knowledge and capabilities that are portable outside of the limited confines of the source code—possibly including but not limited to specific repositories of programs.

Thanks for reading this Management Use Case. I'm the co-author of a new book on software development leadership entitled You.next() that features dozzens of other use cases for leadership. Please see more at www.youdotnext.com.

Getting there

Have you ever read a leadership development book? It’s hard to categorize them all together because there are so many. But two categories do stand out. One group is oriented at people who need to learn to lead and motivate. They are all about getting groups fired-up and committed to goals. Another group is more like the "I'm good enough, I'm smart enough, and doggone it, people like me" of Stuart Smalley fame.

Neither of these categories works for engineers or software developers who need to learn leadership and management. We think in patterns and processes, not in rhetoric. The process of leading needs to be explained in terms that make it a technical function whenever possible. In fact, non-technical managers could use a dose of this approach to tighten-up their style, too. Of course there is a human element of the job that lacks a purely logical approach. That part may be the hardest to learn but it is not a reason to fail in a management career.

Few avenues support a natural evolution into a successful management career leading technologists. As with anything new, setbacks are unavoidable. Without a good coach or the confidence of conviction, potentially talented people can fall back into individual contributor roles bitterly confused, having failed for the first time in their successful technical careers. That is an unnecessary waste and it can easily be avoided with a management development approach that values and leverages a technical foundation. The win-win is that exploring leadership options will teach you a lot about yourself. No matter which way your career goes, you will be in the driver’s seat getting there.

Thanks for reading this Management Use Case. I'm the co-author of a new book on software development leadership entitled You.next() that features dozzens of other use cases for leadership. Please see more at www.youdotnext.com.

Software Development Leadership

How can Apple consistently beat much larger companies with hit products that nobody knew they wanted?

Why do startups thrive when technology is changing rapidly?

Why do corporations follow the whims of capital markets instead of listening to their own smart people?

Those are a few of a thousand questions that all get to the same issue. Scott Adams has asked all of them in his own cartoonist way by turning questions into satire. Plato understood it and has been quoted for 2500 years. Even Ed McMahon understood it too. Curious?

Millions of great engineers, software developers and other technical people are managed every day by managers who do not "get it." Regardless of how good the engineers are, the managers can easily destroy their work faster than it can be produced. Adams invented the pointy-haired manager to exemplify the DontGetian breed. Plato told us loud and clear: if good people are apathetic about leadership, evil people will be the leaders (maybe "evil" is a little strong here - I'm hoping someone will reply with a correction related to the ancient greek term). And as for Ed, he was actually ahead of everyone with the answer, though it was no doubt an anonymous writer’s line: you have to enter to win. Huh?

Too few of the technical best and brightest choose leadership as their career path. They don't even enter the race. They are apathetic about becoming leaders and managers of their peers. And why would they get excited about it, anyway? When management seems to be the path of the incompetent, and technical roles pay well? They would if they understood that many incredibly successful companies achieve that success when brilliant people lead brilliant people. They would if they felt confident in their ability to make a career change without becoming obsolete. They would if they understood what is needed and just how logical and concise good management can be.

But they won't enter the race; they won't even think of it. The state of the industry is to never pull of the greatest talent from the "do-er" ranks into management or leadership because, after all, that would cut back on productivity. It’s the same geniuses that don't realize that good management itself is a great way to boost productivity. Corporations select and foster engineering traits that are completely orthogonal to leadership abilities, and then they populate the leadership ranks with well-meaning but incompetent people. Another generation of software developers and engineers is disappointed with every decision that "management" makes. Scott Adams gets a few hundred more ideas. We all laugh nervously at Dilbert and wonder, just for one second, what it would be like to be in charge.

Thanks for reading this Management Use Case. I'm the co-author of a new book on software development leadership entitled You.next() that features dozzens of other use cases for leadership. Please see more at www.youdotnext.com.