Pawel Brodzinski on Leadership in Technology

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

Category: personal development

  • 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?

  • Embrace Failure

    I failed. It wasn’t very spectacular. Well, if I asked people around they wouldn’t even say it was a failure, but for me it was below-average performance. Thus failure.

    Did I feel bad? I did. I couldn’t help. I knew I shouldn’t but after all I’m just a human. But then I consider it as much better thing which happened to me than just another success. Why?

    Because we don’t learn from successes. We learn from failures.

    When we achieve success it’s like someone was telling us “you’re great, no need to change.” And there is a need to improve. Always. The thing is we usually don’t see it unless we fail.

    The trick is to embrace failure. Welcome it warmly. It is your ticket to another learning session. Yes, you will fill badly for a while, but in the long run it is more valuable than success.

    Failure is an eye-opener. Suddenly you see what you were doing wrong and you don’t understand how blind you’d been not to spot it earlier.

    Failure is a kick in the butt. You feel bad so you know you have to do something to avoid this unpleasant feeling next time. Unless you’re a masochist and you like to feel bad.

    Failure is a helping hand. You get some guidance what you should improve or what you should avoid.

    We are told we should embrace change. I see no reason why we shouldn’t embrace failure.

  • 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.

  • Choose Your Battles

    Organizational changes are hard. The bigger the company is the stronger it defends its status quo. Humans wearing their employee hats aren’t so much different from those wearing their user hats – they like what they know, thus they don’t like changes. But there’s often someone who isn’t happy with current state.

    So you are the one. You aren’t happy with the way your company works. You know what to change. You are even willing to spend significant amount of time and effort to implement The Change. You visualize the new, better, version 2.0 of your organization which will be there once you’re done. And then you rush to convince everyone to subscribe to your vision and fight with those who reject to follow you.

    Stop.

    That’s an easy way to lose, become frustrated, get fired, struggle to find another job and die in misery. Oh, I might have exaggerated with the last one a bit.

    Every organization, even a small one, has its status quo defenders. If you want The Change you, along with your supporters, are likely outnumbered. Trying to fight every single battle will make your group non-existent, which I guess isn’t the best tactic under the sun.

    I’m not saying you should sit there silently waiting for the miracle to come. Try to drop few ideas and observe how people react. It doesn’t take much of perception skills to notice who can support your ideas, who will fight you to the last breath and who doesn’t give a damn.

    You will quickly notice that tiny group of your supporters and crowd of opponents. But then you at least know your situation. And you are able to choose your battles in a way which maximizes your outcome. You quickly learn which discussion can be ignored since they aren’t important. You become aware when discussion turns into flame war and it doesn’t make any sense to continue it. And finally you become sensitive to those small signals of support from people whose opinions you care about.

    You learn to choose your battles.

    If you choose them wisely you win more often. Way more often. And somehow people tend to care about those with a good track record.

    Does it mean you should start a discussion only if chances are good for you to win? No. Sometimes you enter battleground being aware you’ll likely lose. But don’t make it a rule. If there are poker players, who never let it go, they are broke. But at the same time they play, and lose, crappy hands from time to time. That’s just cost of learning.

    If you followed the article you will enter the battlefield at least knowing who you will have to face. You will be prepared. Folks on the other side probably will not. Oh, unless they read that too, but it is unlikely. Why? Because people don’t listen, don’t read and don’t learn, remember?

  • Managers Are Clueless

    So you’re a manager. You even think you’re pretty damn good manager. Fine for me. Do you remember Pointy-Haired Boss? Yes, that clueless manager from Dilbert cartoon. You have this guy sitting in your head. So do I, by the way.

    Is that supposed to be insult? Well, not exactly. I really think every manager has this clueless version of himself in the back of his head which is used more often than we’d like to admit. You still don’t believe me. Do a simple exercise. Think about your team. Arrange members from the best to the worst. Easy?

    It wasn’t supposed to be easy. The trick is how you decided that one ‘average’ person is after all better than another ‘average’ person. Some guessing I guess. Why exactly you have chosen the best one? And what a couple of worst people have done to earn their place? Is it possible that you justify their position with some past event (success or failure) which was spectacular enough they earn the place in your mind? Is it possible you didn’t take into consideration recent history because you already are strongly biased?

    And now the best part, think how many things you haven’t taken into consideration. You haven’t thought about tons of important things and you were still able to say who is better and who is worse from others. And no, I don’t believe none of them are important. Isn’t that clueless?

    A Confession

    I worked with bunches of underpaid and overpaid folks. I saw work which was underrated or overrated just because of person who authored it or the person who judged or both. Many of decisions standing behind these situations were mine. I’m not proud of it.

    What I can say is I didn’t do it on purpose. I just lacked knowledge. Sometimes I wasn’t even conscious my knowledge was insufficient to make a right call. Sometimes I should try harder or think more. I was, and I am, a clueless manager. I try to fight it but that’s an uphill battle. I have my prejudices and preferences and I don’t claim I’m able to fully ignore them.

    The Bad News

    I’m not the only one. I’m tempted to say that every manager is so because the only ones who would be different must be heartless robots which aren’t great candidates for managers anyway.

    This means you as a manager, and your manager too and her manager and so on, are clueless to some point. Usually more than you’d like to admit. This mean there’s a chance your judgments aren’t fair or your work may be misjudged. And finally this means your subordinates can trick you along with your cluelessness to make you think better about them.

    Managers were, are and will be clueless. We may fight with it but we’re likely to fail. Most of us don’t even try anyway.

  • Technical Leadership and People Management

    The other day I had a discussion about leadership and management. When we came to an argument that there’s no chance to advance to a position where you can facilitate leadership and management skills in discussed organization several people (from present and from past) automatically came to my mind. They all have the same problem which they may overlook.

    They all are (or were) great engineers. People you’d love to have on your team. But at some point of their careers they started to think about having their own teams, managing their own people. Hey, that’s natural career path for great engineers, isn’t it?

    Well, actually it is not.

    Do a simple exercise. Think who you consider as a great engineer, no matter if he’s a star book author or your colleague no one outside your company knows about. Now what do they do to pay the rent? I guess they are (surprise, surprise) engineers, tech leads, freelancers, independent consultants or entrepreneurs. I guess there are none who would be called a manager in the first place, even when they happen to do some managerial work from time to time.

    Why? Because these two paths are mutually exclusive. You can’t keep your technical expertise on respected level in the meantime, between performance review of your team member and 3-hour status meeting with your manager. You either keep your hands busy with writing code or you get disconnected with other developers out there.

    On the other hand what makes you a great engineer usually makes you a poor manager at the same time. If you spend all day long coding, you don’t have enough time for people in your team. And they do need your attention. They do much more often than you’d think. If you’re going to be a decent manager big part of your time will be reserved on managerial tasks. There won’t be enough time left to keep on technical track. Sorry.

    That’s why all these people who I thought of have to (or had to) make a decision which way they are (were) going to choose. Technical leadership path means most of the time you won’t have people to manage but you may be respected as an architect, designer, senior engineer. If you’re lucky enough you can even get one of these fancy business cards with title of Chief Scientist or Chief Guru or maybe just a simple Co-Owner.

    Managerial path on the other hand will make you feel lame during basically every technical discussion out there but yes, you will have people to manage. If you’re lucky, and I mean lucky, not competent, you’ll become VP or something.

    You have to choose. Or you had to some time ago. What’s your choice? What do you regret about it?

  • Role of the First Job

    It’s been told a lot about managing your career. How to plan the career, how to get position you’d be happy with, how to push your way through the recruitment process, etc. You can find a lot of reading about the subject (personally I think Rowan Manahan has nice insights in that area), but I think we usually miss one thing here. We kick-off our careers and define our starting point usually quite unconsciously, when we start the first (longer) job. Of course the kick-off doesn’t limit our potential, but usually defines how painful it will be to achieve the final goal.

    The environment which gives you first professional lessons forms you as an employee. And I don’t mean company culture only – one thing is how the organization as a whole is set up but another, even more important, how your team looks like and what kind of persons are leaders. Well-managed, integrated, team with influential leader is a great kick-off to your career. And it really doesn’t matter what programming language you use or what kind of projects you work on. The most important things you learn aren’t technology specific – team work or accountability can be learnt anywhere, customer/user-centric mindset isn’t the thing which is exclusively available in IT only. And a new programming language or project management technique? You’ll learn it when you need it.

    When I think about my career I always come back to my very first team, where I learnt all those basics. I always considered the first professional environment as important but still when I’ve made a little analysis some time ago and results have surprised me a lot. I’ve taken people from my CDN XL team, where I’d grown up and listed what they’re doing now.

    • Our director now co-owns a company
    • Three of team manager owns or co-owns a company
    • One more is a VP
    • Three developers got director ranks
    • One more is a team manager now
    • Three consultants owns or co-owns a company
    • Another three of them are directors now
    • Three more became team managers
    • Four testers moved to more prestigious developer role
    • Two of them got their teams to manage

    Wow. I mean, really, wow. I’ve just counted about two third of the team back then, and it was just a few years ago. What more, I can think about almost no one who wouldn’t appreciate the role of being there when looking from the perspective of their careers. For majority of us that was the first job, for another group that was first job they stuck with for a longer time. Definitely most of us set up our professional standards during that time. I believe the team, the way it was organized and managed and the atmosphere were very important elements of mixture which brought us wherever we are today.

  • Long Career as a Developer

    Software development is a specific role. Acceptable quality is on much lower level than in different areas of our lives. The product is more virtual. New technologies are invited much faster. And people stick to the role for shorter period of time.

    The last thing isn’t typical for all positions in software business. For example there are many long-serving project mangers. By the way that makes much sense, because one of essentials for PM is experience. Although for developers experience is also one of key factors, which decide about quality of their work, long careers on that position are much less often. In the long run developers struggle to outgrow their role and escape to architecture, project management or running own business.

    While I don’t judge that attitude (I used to have the same back than when I was a developer) I think we’ll see more and more positions requiring 10+ years of experience in software development roles. On one hand complexity of systems increases, on the other software goes deeper and deeper into our lives. It’s hard to imagine a hospital without any software working somewhere inside. It’s hard to imagine a new car without at least a couple of processors. It’s hard to imagine a jet without all those cool-looking systems, powered by (what a surprise) thousands lines of code. And it’s so easy to imagine losing life in any of above places. Over the years it’s more and more about the software, its quality, performance, availability and reliability. And developers.

    Developers who make everyday code-level decisions basing on their best knowledge and experience. The more different solution they’ve co-created, the easier is to make the right choice. The fewer mistakes they’ve already made, the bigger is the chance to choose the wrong path. Sure, the team doesn’t have to be built from experienced developers only – it would be neither wise nor cost-effective choice – but leaving young wolves without experienced leader doesn’t guarantee you a success.

    Yes, I hear you talking about Bill Gates or Larry and Sergey, but they were wunderkinds. You don’t see many of those around and most likely you won’t find any in your team. If I was asked who would lead the new complex project when high availability, high performance and high reliability were on the top of the requirements list I’d look for an experienced developer. Someone who has already dealt with performance issues and optimized the code, not the one who doesn’t even know where the performance traps are. Someone who has already designed a couple of poor architectures, not the one who is yet to make those mistakes. Someone who has tried different technologies, not the one who is all hot about the coolest Ruby-on-Rails only. I’d look for that particular type which isn’t very popular among developers.

    That’s why I believe there is high demand on people who stick with development role for a longer period of time and it will grow over time. There will be more and more complex systems to be developed. Definitely that’s an idea to consider if you’re a developer and you’re planning your career.

  • My Micromanagement Experience

    I’ve already written about micromanagement in general. Thing I haven’t yet shared is my own experience with learning how to live without micromanagement.

    When I started having any impact on my colleagues (I wasn’t their formal boss, it was just an informal leader role) I also got some responsibility for a part of development process – it was planning and running functional testing against an application. Because people I worked with were all newbies I decided (surprise, surprise) that I’ll do the most responsible part leaving “my” team the rest. It looked so natural. Hey, who’s the most experienced person here? Who’s the hero?

    There were only five of us, including me, so it worked well that way – the final release was hard earned, but despite 3-week slip I still consider it as a success. I earned my very own team then. It soon grew up as we took over also responsibility for support. And then the model collapsed. I could no longer take every important issue on me. I could no longer check everyone’s work. I could no longer say how to do every tiny detail of our work. More people – more managerish work and less time for the rest. Bigger responsibility – more important tasks to control.

    I was lucky to have quite a good team then with several persons which had already earned my trust, so my lesson didn’t have a big impact on our general performance, but with other people I wouldn’t be so sure if I’d be there, where I am now.

    Later on, my boss asked me who’d be my successor as a manager. I didn’t know, but I told him I’d come with some plan on that. I thought about that: “Hey, I’m the one who know the job – the team is only executor of my will. How they’d know what to do without me?” The Red Light of Micromanagement would blink then if there were any. This was another lesson to learn – the team has to do all the tasks, even most important ones (maybe except of some managerial crappy things no one wants to deal with). “What-ifs” came to support the lesson. What if I went to holidays and something serious would happen? What if a car hit me? What if I changed the job? Oh, wrong example, who’d care than? What if I was promoted than? The answer was always: it would be a problem.

    I found a couple of people and delegate (what a nice word) important tasks to them. Not every single case was delegated, but at least every type of task. I found my successor too. And when I was promoted half a year later, my leaving was totally smooth.

    There’s another lesson I still learn. I work with project managers these days and I’m often tempted to say: do this and that. Act like this. Send the darn e-mail to the darn subcontractor with the darn escalation of the darn issue. To be honest I don’t always restrain the temptation (in other case it wouldn’t be the lesson I still learn). With experienced PMs it’s easier because I know they’ll discuss it with me if they have another idea. It’s harder with those who are still learning the job. I keep reminding myself, like a mantra: “let them decide, let them decide, let them decide, let them…” I know they’ll screw some tasks. However, that way their learning curve will be narrower and they’ll progress to a level when they’ll be tough partners in discussion. Especially when I’ll try to micromanage.

    I think the last thing is the most important one – let people learn. Even when you know they’ll fall, don’t take them through the obstacles on your own back. Let them fall and give them a hand then. Most of people learn on their own mistakes, only some very smart ones learn on others’ mistakes. I prefer to have first two project done with some issues and another ten done well (without my help) than to have first to project done well and another ten facing serious issues, because I can no longer make decisions and PM hasn’t had a chance to learn how to do it himself.