Pawel Brodzinski on Leadership in Technology

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

Category: personal development

  • What Makes You a Great Professional

    I have a small task for you. Think about a few people you know and you consider them as great professionals. Don’t limit yourself to any single role – choose anyone who is great no matter if he’s a manager or a developer or a dustman. Got them? Fine.

    Now a second step – try to name one attribute which is common for each of them. Something which isn’t, by definition, related to specific role or specific job. Depending on variety of people you’ve chosen this can be pretty hard, but try for a while – there must be something. Got it? Great.

    What you’re trying to achieve here is finding a kind of success factor. Something which would differentiate good from great, but at the same time probably not something which would guarantee a mediocre person to become a star. That just isn’t so easy.

    What have you chosen?

    My choice is: urge to learn.

    This is something which constantly pushes us ahead, out of our comfort zone. Even if we err along the way the overall result is positive. As the time passes we get better and better since, well, learning is all about getting better. We grow to the point when someone thinks about us when asked the question from the beginning of this post. We’re not likely to get there though, so chances are good there’s still plenty of room for self-improvement.

    Learning can be a part of your job – in this case you should be pretty happy with it. You can also do a job which doesn’t develop you much at the moment, but it is a lame excuse to stop learning. There are tons of great places to get better at whatever you do or learn something completely new. If you stick with whatever you already know you’re heading to side-track.

    I have great news for you: if you reading this, odds are you have this urge. If you take time to look for content discussing personal development in context of your domain (I don’t expect many dustmen here really) you’re well ahead of the rest of the pack. You’re here to learn something new. Otherwise why would you spend your time reading this?

    If you’ve chosen something else than urge to learn tell me what is your choice and why.

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

  • Too Honest, Too Straightforward

    Vast majority of people working on software products contact their customers directly or indirectly. Yes, software developers included. Each time we do it we play a role of salespeople. Of course customers don’t see us making product presentations or negotiating prices. What do they see then?

    In my case answer is pretty easy since my attitude was commented several times in the past by my colleagues. I’m too honest and too straightforward. It’s definitely a mixed blessing if that’s a blessing at all.

    Talking about business is expected to be like old-school negotiations. Two parties sitting on two ends of the table trying to squeeze others as much as possible using all tricks they know. I hate it. I dream about this kind of discussion:

    – We can do it in 4 months. Here’s proposed schedule.
    – Are you sure phase 2 has to take so long?
    – Yes, since we have to develop integration module for external system. It could be probably a bit shorter if we had experts of that system available but we’ve worked with these guys before and there are always problems with them. If they won’t be an issue this time we should be able to deliver 2 weeks earlier but I wouldn’t bet.
    – OK. Another issue is the price. We won’t pay more than $100000. That’s our approved budget.
    – Let me think… We’d need to cut some functionality out of scope to make it a win-win. How about messaging module and these complex reports?
    – Um… we can let reports go but messaging module must stay. Deal?
    – Deal.

    Yes, I know, I am dreaming. Anyway I often try to bring this kind of approach to the table. Too often. You shouldn’t be surprised if you’re a customer and I ask you: “We plan to develop this product for you, does it makes any sense for you or is that just a brain dead idea?” I may also state: “This function would make both your and our lives easier, although I don’t believe they’d allow me to do it for free. Would you find some budget for the feature? I promise the price will be good.”

    On the side note, if you ever worked as a salesperson with me I know, you already hate me. I guess I must live with that.

    This approach may weaken negotiating position of my party. Sometimes it is considered as pretty harsh by customers since you occasionally don’t wrap up the truth with nice marketing blah-blah (“No, we won’t build and deploy complex telecommunication solution in a month”). That isn’t playing by the rules and from time to time people find it hard to deal with it at the beginning.

    However the thing I found out is that when a relation with the customer is already built they start to appreciate this attitude. Having an honest source of information on the other side is quite a valuable thing. Even when the guy is sometimes too honest and too straightforward.

    It doesn’t mean I’m totally happy with it. It definitely would be better if there were no scary ‘too’ word in the label they stick to my back.

    What kind of person are you? What do your customer see when they talk with you?

  • Difference between Managers and Leaders

    When talking about managers people often confuse two terms: a manager and a leader. The difference is pretty simple however.

    Management is a job while leadership is an attribute.

    You can be promoted to a manager role, but you can’t be promoted to be a leader. To become one you need to work your butt out showing your leadership in the battlefield. You have to inspire people, make them believe they can achieve a goal and motivate them to work harder. Or smarter. Whatever. That’s definitely not enough to tell them “go and get that and better be quick.”

    In normal situation managers, who aren’t leaders, usually end their work when they tell their teams what to do. Micromanagers go even further. They tell what and how exactly thing should be done. Anyway they’re barely a kind of task-dealers.

    Leaders not only point goals and give out tasks but also encourage people to show their own initiative and creativity. They take decisions when it’s needed and are always ready to face any problem team can encounter. You’d willfully follow the leader while you wouldn’t follow the manager if you didn’t have to. Not that you often have a choice.

    Good manager is always a good leader while poor manager is barely a white collar.

  • A Failure Is an Option

    One of my ex-CEOs told me once a story about situation he’d have to face when he’d been a newbie manager. Shortening the story (it’s dull anyway, you can just skip it) a bit there was serious hardware malfunction in a company. There were no spare parts on service stock and they were to deliver their services next day, which was impossible to do without working hardware. The manager felt he had to do something to get machines working again. Unfortunately there was virtually no chance for him to succeed. Company failed to meet their deadlines and he felt as it was partially his fault, which wasn’t true.

    The moral of the story is:

    A failure is an option. Face it.

    By the way I’ve heard the story just after I finally rescued a project after 80-hour over-weekend battle with short brakes to get some sleep. Yes, it sounded totally irrelevant, but what would you expect from CEOs in that matter anyway?

    The moral however is very wise. A failure is an option. Sometimes it doesn’t matter how hard you try there are objective obstacles you can’t deal with. It can happen even if you’re the greatest Project Management Superhero in the galaxy and the biggest projects eat from your hand.

    If you ask me what to do, well, you won’t be surprised with the answer – prepare yourself. Sure, you can sit and cry your eyes out but you won’t get The Most Creative PM Technique Prize for that.

    First thing is to acknowledge you can fail. To be honest most of managers don’t get through this one. You know, you need to tell your ego you’re not as perfect as you think. That’s a tough task. Especially if your ego is so big it goes 5 meters ahead of you.

    Second, to have clean conscience, make sure you did everything you could to avoid failure before giving up. After all you’d prefer to be fairly sure you couldn’t make it, right?

    Third, prepare rescue plan. When you’re finished with hitting the wall hard with your head, have a plan how to call for an ambulance. It was said already that crying over spilled milk or crushed head isn’t the best idea in the world.

    I always smile whenever the reaction for question about potential problem is “we’ll manage, we’re superheroes, don’t ask” kind of approach. And believe me I see that a lot recently. I should have several great stories to tell soon.

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

  • Micromanagement

    Today, I’ll write something so obvious that I’m almost ashamed of it. I thought if there’s anybody who doesn’t know that, but I still see lots and lots of people who act like they should read below advices. There’s a second reason also – it’s always worth to remind to myself these points.

    Micromanagement, that’s what I want to write about today. Why is it bad? There’s a bunch of reasons:

    • Manager can’t do everyone’s work. He has in the team 5, 10 or maybe 50 people, so in every case they do more than a single person could. Even if he’s a superhero. Even if there’s only one person in the team. Remember the manager has his own work. Oh, at last he should have some.

    • Manager’s competence doesn’t cover all competence in her team. She usually isn’t the best developer, the best tester, the best project manager. She has the best managerial attributes. Oh, at last she should have some. That’s why she’s the boss. I hope that’s the reason, in other case I offer my condolences to you.

    • Telling people how exactly they should do their tasks is usually stupid because they usually know better. They are closer to issues, closer to code/functionality/project plan/whatever and they work on that every single day (not only during micromanagement day of the week). Manager is like a driver – he can say if the car looks nice and drives fast. His team is like mechanics – they know what exactly happens in the engine. You’d rather ask the mechanic, not the driver how to fix brakes in you car, wouldn’t you?

    • In these several cases when the manager knows better what to do and how to do, telling people how exactly they should do their tasks is stupid, because people don’t learn accountability then. If the manager taught them micromanaging, they won’t take initiative, won’t be creative and won’t look for improvements of their work. Why should they? That’s the manager who tells them exactly how to work. But remember, she doesn’t have the time to micromanage every single person on regular basis. Even if she’s a superhero.

    Yeah, stupid indeed. It’s obvious. Why to write about that? I’ll answer with a question: why so there’s still so much micromanaging?

    I think reasons are different. When I recall micromanagers I met they’re driven by different demons. There’re two I Know It Better demons – first when the manager really know better how to deal with a task or an issue and second when he thinks he knows. The latter is much more common. There’s Do What I Say demon, when it doesn’t really matters if the solution is right or wrong, it’s all about doing what the manager said just to support his ego. There’s You Don’t Know The Big Picture demon, when micromanaging is justified with lack of wide knowledge about whole situation within the team. Nothing easier but to share the knowledge. There’re of course others, but those are the most common.

    You should listen none of them. There’s always a better way to deal with the task or the issue than micromanaging. You can come with your idea in every situation but don’t treat yourself as unmistakable, because you’re not (I bet). Bring discussion and be open to change your mind if someone, especially someone who’ll actually do the work, comes with another idea. And tell people what to do, not how to do that.

  • My Biggest Mistakes

    Have you ever wondered what were your biggest mistakes in your professional career? Which things you should do another way or at least try to change? It’s usually easy to judge others, especially looking from a perspective of time. Hey, he shouldn’t have left the company then, because now he’d have been promoted at least twice. Easy to say, because it’s about him and you know exactly what happened during those two years after he left. Back then the decision probably didn’t look like a mistake.

    With the same schema we can judge our own decisions, however it’s much harder. First, for most of us it’s difficult to accept that we actually made a mistake. Second, it’s even more difficult to be unbiased when you consider yourself and your own actions. Nevertheless it’s worth a try.

    There’s one thing more – people usually tend to share with others their successes, not failures, so your own experience is even more precious – you have unlimited access to it. You won’t find a lot of “failure stories,” so I thought I’d share some of mine.

    Personal interactions

    When I was leading a support team I had a couple of conflicts with developers partially based on personal background. I thought that if I’m so dedicated and if I struggle to do my best everyone should too. It’s not so hard to imagine that it was rather naive point of view (we worked in a corporation then). Instead of letting other managers to resolve the problem with their people I was making my private tiny war. E.g. we did some performance tests to prove that one of developers didn’t make optimizations, just to show he’d ignored the task. Why didn’t I ask him if he had done that and spent much time for useless tests? Bah, don’t ask me now. You should have asked me then. I can recall several similar situations, all of them having source in my personal likes/dislikes and resulting in, let’s say, not optimal business decisions.

    Building a team

    I was once a department director, building a team and a product from a scratch. By the way it was a great job. I think my biggest mistake then was too slow promotions within the team. For me it’s very hard to promote someone unless I’m completely sure she’s the right person. However I should overcome my resistance instead of waiting too long before official promotion for a couple of the leaders. Not mentioning that I didn’t even thought about potential successors of any of the leaders. Subconsciously I tried to direct my people through the way I passed once: first informal role of leader with real manager controlling whole team and then eventually getting own team and formal managerial role. Unfortunately, I and one of my colleagues changed the job leaving over a dozen of people with no junior and middle management. The promotions were soon carried out, but with people rather unprepared to managerial role and little supervising it wasn’t a vast success. Some time was wasted too.

    Communication with sales

    As a manager of operations team (development, implementations, quality assurance and project management team) my biggest mistake was poor contact with several sales people. I know there’s always a conflict between sales and development, but I’m far from thinking that the technical side is the one which is infallible. Quite the contrary, I even wrote that in general it’s better to have a business person as a CEO and sometimes having a geek as a leader of a company isn’t a great idea. I know all of that, but still I haven’t managed to be on good terms with few sales. And by now I still don’t see how I could get it done right with those people. I’m not even sure if it was possible. Maybe more time has to pass and I’ll find out the answer then. Maybe our characters are too different and we hadn’t even a chance. Nevertheless, the fact remains, it’s my failure too.

    Choosing an idea

    I was working with my friend on a piece of software. Whole thing was intended as a micro-ISV idea, but none of us decided to leave everyday job. In this case our biggest mistake was choosing an application we worked on. It’s not about a market for the application – I still believe we had a chance. It’s about our attitude – we had little fun while working on the software we’d chosen and we reached the point where none of us was still motivating himself, not mentioning about motivating a partner. The software died unfinished. We’d chosen the application only because some of work (part of the code) was already done, so we thought it’ll take much less work to finish. Now I think we had about 5% of work completed, so the choice wasn’t a well-thought one.

    Depending on situation my mistakes were followed by different consequences – in the first situation results were negligible, in the last example whole initiative ended up as a failure. It’s just a bunch of examples, but I can think about a list of others based on both my experience and my observations. Generally, it’s not shame to err – making a mistake once is an occasion to learn, but making the same mistake twice becomes a stupidity.