The books I read for going from Junior to Manager

From Junior to Senior: In high school or at university, you were taught the theory. Read to understand how to apply that theory effectively in the real world.

Working well doesn’t mean just solving problems; it means solving them RIGHT.

I came from the Spectrum. In BASIC, structured programming was difficult to implement, so I was a survival programmer. “Coder To Developer” (Gunderloy) taught me about the pride of developing good code and the practical utility of doing it right, instead of just making it work. Later, I read “The Pragmatic Programmer” (Hunt & Thomas) to solidify what I’d learned. Experience isn’t a matter of years; it’s a matter of learning.

“Rapid Development” (McConnell) taught me many things, but most importantly, that being a Senior had nothing to do with having many years doing the same thing. It’s about learning as quickly as possible to do things better.

“They studied professional programmers with an average of 7 years of experience. They found a 20-to-1 ratio between the best and worst programmers for their first draft. A 25-to-1 ratio in the time they needed to find a bug. The worst programmers wrote programs five times larger and ten times slower. However, they found no relationship between the programmer’s years of experience and their quality or productivity.”

“Rapid Development” (McConnell)

Creative tasks require concentration.

I found “Code Complete” (McConnell) very helpful, a substantial book to be read in small doses. Among the things I took from it, the first definition of being “in the zone” or “in flow.”

“This mental juggling is one of the most challenging aspects of programming, requiring more concentration than other activities. This is why programmers complain about ‘rapid interruptions,’ which is like asking a juggler with three balls in the air to hold your grocery bags.”

Code Complete (McConnell)

“Soft Skills: The Software Developer’s Life Manual” (Sonmez): A kind of management guide for developers that goes beyond software and covers all aspects of life, including finance, health, or relationships. Buy a few copies for the developers you want to promote.

Books that helped me transition from Senior to Team Lead: Managing people is to programming what conducting an orchestra is to playing the violin.

If you’re interested in a management career:

“Making Things Happen” (Berkun) is not only full of advice to guide you through all project situations but also contains advice contrary to popular wisdom.

Just as the conductor is responsible for making the music sound harmonious, you are responsible for making things happen in your project.

Estimating, is it cheating? One of the most complex and requested aspects in the industry is estimation. Knowing how (and especially why) to do them is a differentiator. Fulfilling the estimate is not the goal (nothing easier!). Estimation is something that helps you produce better software.

“The Heroic Effort Complex. If things end well, survivors think that this heroic effort is the main reason for their success. However, there are many bad habits behind this logic.”

“Making Things Happen” (Berkun)

“Agile Estimating and Planning” (Cohn): Change-driven projects challenge traditional estimation techniques. It’s full of advice and examples that can be used in everyday work. Project Managers who forget their history are doomed to repeat it.

If you work in software, the equivalent of Greek myths is “The Mythical Man-Month” (Brooks). With this book, you discover that all your problems, ALL, were experienced by others 50 years ago. What’s new is only what we’ve forgotten.

If you’re not SO INTERESTED in management but want to remain tied to the technical side, there’s an equivalent for Technicians who will manage technicians: “Herding Cats: A Primer for Programmers Who Lead Programmers” (Rainwater).

“Planning is usually something your boss launches [it has to be ready by Christmas], and you have to fill in the details. Two steps forward, one step back. It’s a recursive process. You’re continually shaping a big plan to fine-tune the details you’ll manage.”

“Herding Cats: A Primer for Programmers Who Lead Programmers” (Rainwater).

And another one for planning without having to plan (so much): “Getting Real” (37signals): A smaller, faster, better way to build software. The Basecamp team has updated it with “Shape up,” but my recommendation is to start with the classic.

From Project to Product: It’s VERY different, and you need to know why, or you’ll end up working on a “proJuct”!

The key to projects is constraints. Time, cost, scope… you know. But how would you manage a project if you had no constraints at all? They explain it in “The Deadline” (DeMarco), which is a pleasant and easy-to-read novella.

Quality, the great forgotten when it’s time to cut time and cost and expand scope. Some advice for implementing systematic quality without costing you your life in “The Checklist Manifesto” (Gawande). Also on quality, “The Ice Cream Maker” (Chowdhury) is a novella where step by step, you’ll see what it means to implement a management system.

I remember my coach used to tell me, “Don’t judge the goalkeeper on their best day. Judge them on their worst. When they play poorly, will they make you lose the game? Or are they good enough to keep you competitive even on their worst day? Well, I judge companies the same way. How do they perform when problems arise?”

The Ice Cream Maker” (Chowdhury)

Toyota changed the way products are manufactured in the automotive industry. If you want to make quality products, you should take a look at it. “The Toyota Way” (Liker).

“People do what their bosses tell them. If that’s consistent, if they’re not confused by different priorities, they’ll learn what really matters and what doesn’t. The top two priorities are ‘quality-first’ and ‘safety-first.’ Extra effort. Extra care. It’s the kind of culture we expect to create, and it guides our business.”

The Toyota Way” (Liker).

If you work in software, the equivalent of reading “The Toyota Way” is “Lean Software Development” (Poppendieck).

From the technical side to the management side: it’s like an economist starting to learn Java.

Creating good solutions is one thing. Creating solutions you can sell, and knowing how and why you can sell them, is another. “7 Powers: The Foundations of Business Strategy” (Helmer) provides a framework for understanding why some products succeed while others, possibly objectively better, fail. You can start applying it to your daily work from page 10.

When you move away from the technical side, delegating is not an option but part of your job. “If You Want It Done Right, You Don’t Have to Do It Yourself!” (Genett) provides the basic rules for delegating effectively.

  • Prepare well what you’re going to delegate.
  • Explain the task, its deadlines, and the level of authority you grant clearly.
  • Establish regular follow-ups, including after the task is completed.

If you’ve ever said, “The Japanese say ‘yes’ when they mean ‘no,'” “These Americans are so rude,” or “I can’t trust the deadlines I get from Latin America,” “The Culture Map” (Meyer) is your book. The word of the year was “Kuuki Yomenai,” which means “the one who can’t read the air,” someone who doesn’t understand the unspoken. If I’m in a meeting in Japan, and someone is showing disagreement not explicitly but implicitly, I have to read the environment to appreciate that disagreement.

One of your most important jobs will be to say No. “When I Say No, I Feel Guilty” (Smith) provides techniques to improve your assertiveness, which is incredibly helpful for introverted technicians.

How to avoid promoting a great technician into a bad manager?

(Leer en español / Read in spanish)

How to avoid promoting a great technician into a bad manager? If you turn your best developer into a project manager, you will lose a great developer (who is bad at managing) and gain a bad project manager (who is even worse!)

The Peter Principle (“Every person rises to their level of incompetence”) warns us against promoting people who do not have the skills or interest to perform management or leadership positions.

What is the solution? Promote them to a leader, but not of people.

When the only way to advance is to become a manager (soft skills, monitoring and control, business knowledge…), you force the best technicians to work outside of the T-vertical (the technological knowledge that makes them great technicians). What other ways are there (or should there be) to promote a technician?

.1- THE SPECIALIST: Deepening their knowledge in the same field they are already in (T knowledge, with the T becoming longer 😉) to become the company/industry reference. .- Consequence: The Specialist will be called upon to solve problems in different domains (banking, aerospace, insurance, etc.), which will also increase their horizontal knowledge (the wide line of the T).

.2- THE JACK OF ALL TRADES: Developing knowledge in Pi (or in m) and specializing in different technologies (full-stack?). .- Consequence: The Swiss Army Knife will get involved in more and more parts of different projects, using one or several of their specializations.

.3 – THE TECHNICAL LEADER: Both the Specialist and the Swiss Army Knife have the opportunity to become leaders. But not leaders of people (soft skills, monitoring and control, business knowledge…), but leaders of solutions (which technology to use, critical architecture decision-making, which best practices to systematize…)

A leader doesn’t have to manage people. A leader can be a solution leader.

A great technician can be a leader, even if they don’t have the skills or desire to manage. A great technician can be a leader of solutions, instead of a leader of people.

Paying different for the same position makes total sense (sometimes)

Can I pay someone more for the same job? Actually, yes. It makes sense that two people doing the same job have different salaries.

Yes.

Not always. Not everytime.

But yes.

When I develop professionally I can grow:

.- in depth (in I), knowing more and more about my specialty.
.- in width (in T), knowing more and more things besides my specialty.
.- and when I develop several specialties I can grow in π (or in m)

If a specialist in I coincides in the same position as a T, both are developing the same position, but the T adds more value to the organization (can solve more questions about their work or the work of others).

At the same level of depth in the specialty (equal height of the letter) the person in T contributes more than the person in I.

And the person in π contributes more than the person in T.

If I am paid less for the same job, it may be unfair… or I may need more training.

Infinite games, competitive vs colaborative, entertaining vs winning and business vs wrestling


People don’t consider wrestling as a sport anymore.

But it is.

Life is a game

It’s not a wrestling competition. Right.
It’s not competition in the sense of a match with a non-pre-determined winner or loser.

But it’s sport.

The REAL result of a wrestling match is difficult to figure out until some time has passed by. Sometimes the scripted winner gets a bust in merchandise sales or gets more on-air time. But often is the loser the one whose career is pushed up, specially if he’s been defeated in an epic or controversial way.

Because of this, both wrestlers cooperate to get the best match ever, the one in which the audience gets more involved, they both try to steal the show.

Because wrestling scoreboard is not about losing or winning matches, but about attracting viewers through telling compelling, interesting stories.

And this hidden scoreboard is the one turning a show based on faked competition into an actual cooperative sport.

What are my team’s inner scoreboards for turning the work into a cooperative value-creation non-zero-sum game, instead of a competitive, status zero-sum game?

If I don’t have any, I should start getting some.

Hint: If you don’t like the competitive game you are playing, change the rules, because if you are not choosing the game you are playing, someone else is chosing for you.

Bonus track: Sports are competitive, war in disguise. Conversations are not. Next time we start a negotiation, it could be useful to treat it as a conversation, not as a competition.