Pawel Brodzinski on Leadership in Technology

Whatever it takes to lead a team, build a product, and run a business

Tag: people

  • Happiness Index as Team Sustainability Metric

    One of the discussions that happened during Don Reinertsen’s product development workshop was the one about absorbing turbulence. Absorbing turbulence is a metaphor for how well a team deals with unplanned variability of the process. These would be situations like arrival of a bigger batch of features to build, or especially complex work items, etc.

    Normally, every team is suitable to absorb some turbulence. Beyond that point this capability will not be sufficient and the situation would quickly escalate. A good example may be that the team would gracefully deal with some additional features but above certain threshold we’ll quickly the situation escalating to a high queue state. This would result in long lead times, long feedback loops and generally decreased responsiveness of a team.

    These all result in lower efficiency too.

    If such a situation persists over longer period of time it can take a heavy toll on people as we are running at risk of burning people out.

    I really like the analogy that Don uses in his work: when a human body is losing blood, interestingly enough, blood pressure doesn’t go down. What our body is designed for is to pump enough blood to the brain so it can operate normally.

    To compensate for losing blood the heart rate keeps going up. It goes up to the point where this mechanism is no longer sufficient and the organism crashes over a very short period of time.

    A similar thing happens when we overload our teams. For some time they deal with the overload just fine introducing their own coping mechanism. They’d likely work overtime, introduce additional multitasking, etc. A problem is that, similarly to the situation when a human body loses blood, there’s a price to be paid for that.

    Eventually people end up burned out and leave an organization. From that perspective a good question would be: what kind of early signals we get so that we can address the problem early.

    One answer would be careful monitoring of work. How much work in progress we have. How our queues in backlog change. This kind of stuff. While obviously that would provide us some signal, that wouldn’t really be a proxy measure if we want to consider people first, not the process first.

    What strikes me is that we at Lunar Logic already use a nice signaling mechanism that would give us an early warning. The mechanism is a happiness chart. Despite the fact that a happiness chart is a super simple, super low-tech tool it works on a few levels.

    On one level we have individuals. When I see a deviation from the norm in the chart of one person it likely means that something’s going wrong. It may be related to the work, it may be related to a personal life. Whatever the case is it does affect the work.

    If the case is individual it will unlikely be related to the whole project.

    Another context is the one of the whole company. If things were going generally wrong I’d expect to see a strong signal across the whole board. “Generally wrong” may mean either mediocre business results, or a cultural problem, or a strong source of frustration, or a bunch of different things.

    In such situation the signal would be broader than just a single project or product team.

    There’s another scenario, which would be a bunch of people recording worse than typical mood and the correlation would be around a common project. Process-related parameters of that project may look OK: a backlog queue wouldn’t grow, throughput would go up, etc. Is there anything wrong then?

    In this case happiness chart would serve as blood pressure – it would be a countermeasure pointing that something is going not exactly OK and if we keep doing that we may end up crashing.

    The rule for our happiness chart is that the color translates to the mood. Green means happy, blue means so-so, and red means not happy. Once the chart for a project team gets more bluish or even reddish that’s a very strong indicator that we are not absorbing turbulence in that team gracefully.

    The interesting part is that a happiness chart would provide such an information no matter whether a root cause is overloading a team with tasks, interpersonal conflicts that affect collaboration or anything else. The alarm would go off in either case. That’s actually perfect as we want to react to dangerous turbulence early in any situation.

    From that perspective the outcome of happiness chart isn’t a leading indicator per se – when the change is triggered it means that there’s already something happening. It isn’t a lagging one either. We can correlate it with other parameters or even check with people to figure out what is happening. We would know that we’re not coping with turbulence well enough much earlier than when we are on the verge of crashing.

    The reason why I think this strategy is so valuable is because it allows to merge the data from two different universes. On one hand we have all the process metrics that tell us how we are doing from efficiency perspective. On the other we get a social metric that tell a lot whether the current state is sustainable.

    It is exactly like a combination of a blood pressure and a heart rate. The former translate to efficient work of our steering center – the brain. The latter tells a little bit how sustainable current conditions are.

  • It’s the People, Not the System

    When I first learned about the D. Edwards Deming’s idea that 95% of performance should be addressed to the system and only 5% to the people it seemed totally counter-intuitive to me. Not even the idea itself, but its consequences. I mean a simple thought that you can basically stop working individually with the people on their performance as it just doesn’t make any sense. The impact of suboptimal system improvements should be tenfold or better than the best possible people-related changes.

    Then, after researching the subject a bit, I swayed to the other side. The examples shared by Deming or Eli Goldratt are undeniable. I can also find a lot of examples from my own experience how the system was impacting performance heavily. Not that I had the numbers, but it resonated well with me.

    Now, finally, you know what I think? Both approaches are crap.

    Yeah, I’ve just tried to piss of both: guys who strongly believe in Deming’s work and those who totally disagree with him with a single attempt.

    What Deming Really Said

    I guess this story started when I was looking for precise Deming’s quote on one occasion. It seems that the meaning people attach to his words wasn’t there initially. The original 95/5 thingy was not about performance literally but about variability in performance.

    Let me use a sport analogy to explain that. Let’s take a basketball player. If he scores anything between 5 and 30 points a game, and neither of extremes is an extraordinarily good or an extraordinarily bad game for him (meaning: it happens on occasions) variability of his performance is high. As a comparison we can have another guy, a second-tier player, who regularly scores anything between 0 and 5 points. Variability of his performance is significantly lower, even though his average performance is significantly worse.

    Now, it’s not a surprise that the system governs variability. I mean, the more repeatable the situation the less variability you can expect. If the team plays are consequently set to create situations for one player his performances will be sort of repeatable. He won’t be suddenly disappearing from the game. At the same the system also governs variability of performances of a role-player who joins the game only under special circumstances, e.g. when the team needs more three-pointers or maybe when one of important players is injured. Variability of performances of such a player will be significantly bigger.

    Of course, to some point, the system also governs performance itself. Think what happens when the star sits on the bench throughout the whole game or when a guy who is typically a sub plays the whole game. It doesn’t mean, however, that you tell a third-tier player to substitute a team leader and expect them to score 30 points a game. It’s not going to happen in a consistent manner. (For basketball fans: yes, I know Jeremy Lin’s story, but that’s an exception.)

    What Deming was talking about was basically that the system governance is responsible for creating a stable and repetitive environment so people performances are controllable. Again, it’s not about how exactly people perform, but how their performance varies from day to day.

    In fact, the above statement is mostly an interpretation too. Deming was talking about the system being, or not being, in statistical control which isn’t exactly performance variability, but for the sake of this argument let’s leave it as it is and not complicate things even further.

    Anyway, Deming Is Still Wrong

    So far I made an attempt to convince you that: first, Deming was basically talking about performance variability and second, the impact of the system on performance itself, while existent, isn’t anywhere close to 95%.

    However, we shouldn’t forget Deming’s background, which is a factory floor. In other words it’s a place where workers are supposed to produce same things in a repeatable manner. I could exploit the basketball analogy further pointing that every game, heck, every play is different, but I guess in software development we simply don’t need that analogy anymore. It’s enough to ask: how many times have you built exactly the same feature?

    And for all three of you who accidentally had this chance: how many times have you built the feature second time in exactly the same way you did the first?

    I bring this argument to show that in knowledge work, or sports, we naturally have significantly higher variability to deal with. And, unlike on a shop floor, that is good. What’s more, there is a different value attached to every single thing we develop. In fact, it’s even worse than that. Very often we don’t know exactly what value is attached to a work item we’re going to build.

    This means that in such a situation we should use a very different statistic mechanism than Deming based on. We need to take into account both expected cost and expected payoff. The latter, naturally, isn’t taken into consideration on a shop floor as in this situation payoff for each part is well known. In knowledge work, on the other hand, payoff function is extremely important and never flat.

    Coming back to the basketball analogy: if you wanted to bet which player is going to score 30+ points during the next game would you rather choose this reliable guy who averages 15.0 and who always scores double-figure but rarely, if ever, exceeds 20.0 or rather that crazy shooter who (surprise, surprise) averages 15.0 as well but, depending on a day, can score either nothing or 40+ points? Bravo! You’ve just chosen higher variability, which is totally against what Deming taught us.

    This is because you’ve taken the payoff into account. In the former case any payoff is almost impossible as, because of low variability, it’s highly unlikely that the guy is going to score 30+ points. The other case is a different story though.

    Now, especially when we think about product development we are in a betting business. We bet that this or that feature will bring a ton of new users or a truckload of money. We can’t ignore the payoff function. We can’t assume the payoff function is flat. In either case we’d be throwing the baby out with the bathwater.

    By the way, if you want to dig deeper around this one I strongly recommend watching this Don Reinertsen’s session. Twice. Seriously.

    Besides, Who Does Create the System?

    I’m not done yet. I don’t challenge the idea that the system affects performance. I simply challenge the so-called 95/5 rule or, to be more precise, I challenge the way some people interpret the so-called 95/5 rule.

    The question we should be asking is who (co-)creates the system. If we start with Deming he points shaping the system as a management responsibility. This is probably very true on a factory floor. We are not at a factory floor though.

    Let’s stay for a moment within software development perspective and think what exactly an equivalent of a production line is.

    Obviously, one part would be organizational culture. What are general ways things are done in the organization? Does the org use a lean / agile or rather a heavy-weight, formalized approach? How do your clients act? These general rules will be difficult to change.

    However, when we consider a lower level it’s a different game. Let’s try to translate low-level manufacturing process to software development. Production line would likely be a sort of a process: analysis, coding, testing, deployment, etc. What’s interesting though is what is happening on each of these stations. How exactly the work is done? Who makes decisions how the work is done?

    Take coding for example. Who decides whether unit tests are there or not? How many of them? What kind of tests? Who decides on a specific coding style? A manager? Um, no, not really. Most, or even every, of those decisions are made by a coder – a worker.

    Now, the important question: do such decisions define the system which a developer operates in? Obviously! Just think what is going to be the outcome of work of a cowboy coder and what happens when a worker is an eXtreme Programming fan. These are different systems indeed.

    The conclusion of this story is that in our world workers can influence the system heavily, thus completely change the Deming’s equation.

    One might point that leaving people freedom and empowering them is still the part of the system design which is still the management job. I’d disagree. One thing is that adopting a technique or a practice isn’t comparable to moving the machines on a factory floor. I can perfectly start writing unit tests and it doesn’t instantly require everyone else to change the way they work.

    Another thing is that it’s way easier to be a Grace Hopper follower in our industry. We can easily change the part of the system that goes through our desks, no matter whether we are empowered to do so or not. Eventually, if anyone notices (which isn’t that obvious by the way) we should have enough information to have meaningful discussion about the impact of how we’ve done our work.

    All in all, in knowledge work there’s no clear line that separates the system from the people, thus the whole notion of addressing specific part of influence to one or the other is flawed.

    It’s the People, Stupid!

    The last piece of this puzzle is a story. Not that long ago I’ve joined the organization that is exceptional when compared to its surroundings. I’m far from saying that it is a perfect system already, but it’s definitely the most mature company that I’ve ever been working with.

    In fact, it’s not only maturity of software development process we have but also this touchy-feely stuff we call the atmosphere. Not a dream job (yet) but pretty damn close to it when compared to everything else I’ve had a chance to experience.

    Let’s try to translate this to a system definition then. It would be pretty effective. It would be delivering high-quality stuff. It would be a great environment to work at. It would help everyone to grow. How could one possibly not like it?

    The only problem is that I’ve lost one third of technical stuff over the course of few months. The system? No, the people! Their individual needs, frustrations and dreams. Their unique contributions to what the system is, or has been.

    Because at the end of the day, in our world, the system is not machinery with replaceable humanoid parts; it is inseparably connected with the people who operate within the system. Change a single person and the whole system is different. Suddenly the rules of the game have changed and everyone else operates in a very different system. And the only thing that has changed is a single person has left.

    Summary

    My message in all that is that we should first understand our work, how it gets done and what kind of system we operate in. Because when we think about that it becomes obvious that there’s no simple way of separating the people from the system in knowledge work domain, especially when we’re talking about a small scale, e.g. dozens of people, not thousands of them.

    At the same time I’m challenging the common notion of Deming’s rule because it’s nothing close to what Deming really said and it is simply flawed in our domain anyway.

    At the end of the day you should understand the system (obviously!) but focus on the people too if you want a significant change.

  • People Are Not Our Most Valuable Resource

    I hear that one from time to time: “people are our most valuable resource.”

    Well, they are not.

    People aren’t your most valuable resource. People aren’t goddamn resource at all. People are, well, people. Individuals. Folks who somehow like to be treated as real persons and not precious pieces of junk otherwise known as servers and such.

    Every time I hear this cliché about people being most valuable resource I wonder: how the heck can you say people are most valuable when you treat them as resource? As commodity. As something which can be replaced with another identical um… resource. If you say that, you basically deny that people in your organization are important.

    And it doesn’t really matter how hard you try to avoid calling people with that name. If you believe they are (put here “most valuable” or whatever bullshit you like) resources you won’t trick them. They won’t feel respected and they won’t trust you. Why should they after all? Do servers trust project leaders? And no, that won’t make people motivated whatsoever.

    I know, this is a rant. But this makes me crazy. I mean, how could we learn such humiliating behavior? I’m just waiting until I hear “Hi resource” instead of “Hi Jane” when Mr. I’m-So-Damn-Important-Project-Manager meets one of his project team members.

    Then, I’m going to hurt somebody. And I guess it won’t be Jane.

  • Being a Leader

    Recently a subject of leadership pops up on Software Project Management pretty often, but usually I look at it from manager’s perspective. After all that’s something I do for living – managing teams. So yes, being a leader is the first and probably the most important role of manager (by the way, the post on role of manager turned into full-blown presentation which causes some buzz every time I deliver it). But leadership isn’t exclusively attached to management.

    We are leaders in our workplaces, but we lead in different communities and informal groups as well. And even if we stick to our professional lives we can lead in technical areas or be typical people leaders. Leadership has many names. This was exactly the theme of my recent presentation on the subject which I delivered as a guest on Toastmasters contest.

    Being a leader

    A very interesting discussion followed the session. I used leadership definition I’ve heard from Mary Poppendieck: “Ability to attract followers is exactly what makes you a leader.” The definition neatly covers all sorts of tech leads – if I believe you’re knowledgeable and experienced person in a specific area I will come to pester you every time I need help with that matter. In other words I will follow you, which according to definition makes you a leader.

    The argument against that approach is that we call it authority and not leadership and leadership is/should be discussed from a perspective of leading teams/groups. I can’t say I agree with this point of view as we’d have to cross out many leaders who build their follower base thanks to extraordinary knowledge and technical skills. What do you think?

    By the way, after criticism I faced on my slides from AgileEE I built this slide deck differently. Happy now?

  • The Role of Manager

    I took part in a very interesting discussion today. We were talking about criteria we should use to appraise leaders and managers in the organization. The most surprising part, at least for me, was discussion about notion of line manager among disputants.

    It came out that we considered average functional manager as anything between pure-manager to person who does 90% of engineering work mixed with 10% of managerial tasks. That’s a variety of options, isn’t it? As you may guess I supported rather the former than the latter.

    Well, if I’m such an opponent of letting people do what they used to do before they were promoted to management, likely coding if we talk about software teams, what I think they should do all day long? In other words what is, or should be, the role of manager.

    Leader

    This vague term describes first and most important trait most managers should have and only few have. If I’m a team member I expect my manager will show leadership and charisma. I want to be ignited to follow his ideas. I need to be sure he knows why and where we are heading. I have to see him around when problems arise. I eager to be managed by someone I’d like to follow even if no one told me so. A good manager is also a good leader but these two are not the same. What a pity it isn’t common mixture.

    Coach

    Help newcomers with learning the organization. Help inexperienced with gaining experience. Help everyone with growing. Help those with problems with fixing them. Easy? No, not at all. First, you need to know who needs what. Then, you need to know how to reach people so your helping hand won’t be rejected. Finally, you need to work carefully and patiently sharing your knowledge in experience in a way which doesn’t frustrate or dishearten people. Repeat when finished.

    Shield

    As a line manager you have some senior management over your head. This is a bad news. Actually there’s usually a lot of crap flying over there and, because of the gravity, it’s going to land down on heads of your team. There will be blame games. There will be pointing fingers. It is your time. Be a shield. Take enough bullets on your chest for the team. You’ll earn respect. You’ll earn a bunch of loyal followers. And that’s how you earn your spurs.

    Advocate

    As a manager you’re also an advocate. Devil’s advocate to be precise. You have to present and defend different decisions made up there, in the place where only C-level execs are allowed. Sometimes these decisions you won’t like. But for your people you’re still the face of the company so don’t play the angry boy and act like a man. We don’t always do what we want. After all, they pay you for this, remember?

    Motivator

    Sometimes everyone needs a kick in the butt to get back to work at full speed. It would be quite a pleasant task but unfortunately kicking butts is used as a metaphor here. It’s all about motivation. And I have a bad news here, there’s no easy answer for a question what motivates people. You have to learn each of your people individually. Oh, forgot to mention, it takes quite a lot of time to learn what drives all these people.

    Adviser

    Yes, an adviser. Not a decision-maker. At least not unless you really have to make a decision by yourself. People will come to you asking different things. Well, they will if they think your opinion may add some value and you’re capable to understand what the hell they are talking about. Of course you can guess or shoot or use magic 8 ball but you better learn (oh no! more learning) what the problem really is and help your team to solve it. Note: it is different than solving it for them, even if you know the answer. If an association which comes to your mind is delegation I must praise your reasoning.

    Now if you are done with those and still have enough time to keep up your outstanding engineering skills, please do Mr. Anderson. Unfortunately chances are good it is enough to fill more than a full working day so you’d have to choose between focusing on your management or technical skills.

    And if you happen to spend two third of your day coding, well, I dare to say you aren’t a manager I’d like to work for. Your people would say the same, but you don’t talk with them so you don’t even know. After all there’s no time to chit chat, you have to code, right?

  • Don’t Promote Best Engineers to Management Positions

    I remember one of first post ideas for this blog back then, 4 years ago. It was about choosing people to promote them to management roles. I’ve never published the post and I’m glad about that. A few years ago I didn’t know about hiring and promoting managers more than typical decision maker in IT companies now.

    I knew nothing.

    During these few years I’ve met a number of managers who should never be promoted to any position which touches leading people whatsoever. I mean they were great engineers once. But engineering, and software development isn’t an exception, and management are two different things. They don’t even rhyme with each other. So why the hell do we keep promoting our best engineers to management positions?

    Vast majority of best developers I’ve met were crappy candidates for managers. They were thinking in terms of code, not in terms of people. And a manager isn’t the go-to-guy when you have a technical problem. (The guy is called Google by the way.) A manager should work with people, not with code, architecture or build server. Yes, the transition is possible. Hey, if someone is willing to pay me real money for managing people it is some kind of proof. But the switch is painful and time consuming. And unfortunately most of the time it just doesn’t happen.

    We end up with a lot of people around who are still good-to-great engineers but crappy managers. And we let them lead. Then, when we need to promote someone even higher we have basically no good choice. And we end up with a bunch of managers-by-accident all over the organization. As a side effect you lose your best brains when it comes to engineering.

    Skills required to be technical leader and people manager are so different it is highly unlikely that your best engineer is also your best candidate for a manager. You can safely assume your engineers aren’t different. Why should they?

    If you want to offer your best engineer management position, rethink it. Twice. Is it possible you do it because it is exactly how things were done around for years? Is it possible you’re going to lose great developer and gain crappy manager instead? Is it possible to find a better candidate within the team or outside?

    If the answer is triple yes, and surprisingly often it is so, you’re doing wrong thing. I would even say that sometimes it’s better to let your great engineer go than to make him a manager. Of course if he is a crappy candidate for management position.

  • We Know Nothing about Our Teams

    I am a chatty guy. Catch me while I’m not overworked and I will gladly jump into discussion. If you happen to be my colleague, it may be a discussion about our company. That’s perfectly fine for me.

    I believe in transparency so I won’t keep all information as they were top secret. This means I’m likely to tell you more than your manager. Not because I don’t know how to keep a secret but because vast majority of managers talk with their teams way too little.

    With this approach I usually know a lot of gossips told in companies I work for. Since I also happen to fulfill rather senior roles I have another perspective too. I know what is discussed on top management meetings.

    This is sort of schizophrenic experience for me because almost always I have two different pictures of the same thing. I see senior managers praising people who are disrespected by their teams. I see folks who get credited for the work they didn’t do. I see line workers being completely frustrated while their managers are saying these guys are highly motivated. I see managers completely surprised when people suddenly leave while almost everyone saw that coming for past half a year.

    I see it and I don’t get it. All these managers do very little, if anything, to learn a bit about their people but they claim they know everything. I may be wrong but I believe I do much more to learn about my team, yet I still consider I know nothing.

    If one of you guys is reading that, yes, I’m stressed that you might leave. I’m stressed when you get out of the room to pick the phone since definitely it is a headhunter who’s calling. I can’t sleep when you take a single day off since, and I know it for sure, you have an interview. OK, I might have exaggerated a bit. Anyway in terms of my knowledge about my team I know that I know nothing.

    And you know what? If you are a manager you are no better. Because generally speaking we know nothing about our teams. Even if we are friends with our subordinates our professional relationship is much of unknown. With strangers we usually work with it is much, much harder.

    Stop expecting you know oh so much about your people and at least try to talk with them. If you’re lucky you may find a couple of folks who actually are willing to talk with you. Remember though, if you ignore them once or twice they aren’t coming back to you.

    It looks like I have a pretty poor opinion about quality of people management in general. Well, I must admit I do. I would be a hypocrite if I deny it regarding my recent posts on subject: