Pawel Brodzinski on Leadership in Technology

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

Author: Pawel Brodzinski

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

  • Post Mortem Basics

    What is it?

    To make long story short post mortem is a little discussion after a project or important part of project. The team discusses what was done well and what was screwed. Before discussion one person gets feedback from all team members to bring a food for thought. Outcomes are used in future projects.

    What’s in it for me?

    Why to do post mortems? You usually feel what went wrong and what went well. But do all team members feel the same? Does a developer care if communication with a client went perfectly? Does a project manager understand all architecture flaws developers had to face? Does quality assurance team was aware about complex hardware installation part?

    Post mortems bring two main outcomes.

    1. Knowledge sharing. Everyone adds their two cents. All perspectives are included. Even the least important team member can bring a refreshing insight about project.

    2. Written summary. The process of preparing post mortems forces a person to prepare a piece of document before discussion. You just raise your chances to have a written summary after all which won’t fade in a week.

    How to do it?

    The scenario is simple:

    1. A person who knows a project well, ask all team members to answer three questions:
    • What went well and should be repeated in future projects?
    • What was on a good path and should be improved in future projects?
    • What went wrong and should be avoided in future projects?

    2. Then the person needs a lot of squeezing to get answers from most people from a project team, as many people won’t just answer a polite request.

    3. All answers are assembled into one summary. That’s part can be tricky as it sometimes happen the same thing will be put in different categories by different people.

    4. The whole thing is discussed and adjusted during team meeting, when everyone can add anything what comes to her mind.

    5. Post mortem can be, and should be, used to improve future projects.

    The questions can be adjusted if you feel like it, although I find the more general they are the more interesting things people will bring in answers. You don’t force people to change their perspectives, you just let them exploit their area of competence.

    When to do it?

    Definitely when a project is finished. But when you run a project which lasts three quarters you won’t remember all the issues you had to resolve during first phases after all. Then it’s quite a good idea to run post mortems after each important milestone.

    When you shouldn’t bother?

    If you don’t plan to use post mortem outcomes to improve future projects, don’t waste your time. Looking back is worthwhile only when it is a tool to improve future.

  • A Measure of Good Management

    One of measures of good management is a number of situations when people, not a manager, decide how to do things. When the manager allows people to make their decisions. Let them become accountable.

    I’d like to see technical design document, but you decide what should be in, what out and how the whole thing will look like. Hey, you guys will be working on that later, not me.

    We need formalized risk management in the project, but it’s you who decide how to run whole thing. You know a project team better. You know what will and what will not work.

    We have some emergency in server room in another city and it has to be dealt with. Find a way to fix the problem and to minimize impact on other tasks. I don’t have all the data to make the best choice.

    The more you hear those kinds the better manager you work with.

  • Money as a Motivator

    OK, the subject will be controversial. Money as a motivator. If you ask people what motivates them to work, they’d throw a bunch of different things much more often than they’d say about remuneration. Self-development options are evergreen here, but good atmosphere, top technologies, interesting products or well-organized processes are all mentioned more often than pure cash. By the way that’s one of my interview questions and, believe me, I hear “money” much, much less than I’d expect. Rob Walling presents quite a long list of different qualities which are valued more than money by developers. That’s first perspective.

    Another one is pointing money actually does no good in the area of motivating people. David Carr in his post about money as a motivator shows a list of examples where money doesn’t really affect positively people’s work or even harm their attitude and, as a result, effectiveness. That’s other perspective.

    Personally I strongly believe in non-monetary motivating techniques. “CEO’s handshake” followed by several words of praise can have much more impact than a payload of money. That’s another perspective.

    Having said all of that, ask people if they’re willing to change the job for a better one in almost every aspect they can imagine. Better atmosphere, cooler technology, more interesting products and wide range of possibilities to self-develop. The only worse thing would be money. Few would follow. And if you leave aside those who are starting their own businesses you end up almost empty-handed.

    Now, do another test – situation is the same but in the second job money is better, but e.g. atmosphere is worse. More candidates? What a surprise. Oh, is that really such a big surprise?

    OK, where’s my point then? There are a few of them actually:

    • Money alone doesn’t work very well when you want to add motivation over the standard effort.

    • Money is very often used wrong. If it is so the result are usually opposite than intended.

    • When used well, which is rather rare by the way, money can work as a motivator.

    • Non-monetary motivation techniques are essential but they don’t substitute remuneration – they supplement money.

    • Money is more important for people than they’d be willing to admit.

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

  • Eliminator Questions during Job Interview

    Two sources made me thinking about recruitment process once again. One was Rowan Manahan with his post about eliminator questions. Another was a series of interviews with potential summer interns I had last days.

    Rowan lists several questions which, if answered badly, can ruin your chances for a hire. On his personal list you can find:

    • Telling about your career

    • Telling something negative about you

    • Giving reason why you should be hired

    • Questions you ask

    I asked myself if I can make a similar list in my case. I followed my last interviews with potential interns and I can’t make similar blacklist as Rowan. I can’t think about any single question which answered poorly can ruin chances of the interviewee. On the other hand, it’s possible to ruin the chances giving really poor answer for any of questions.

    There’s another area where I can’t consider myself as a typical interviewer, described by Rowan, as I usually start with a positive (not neutral) attitude to the candidate. When I recall my last recruitment meetings I try to enter the room with a slight will to hire the person. This helps me to create friendly atmosphere and (I hope) moves some pressure out of the candidate.

    I think that’s fair. You have never a chance to make the first impression for the second time and interviewees are stressed, they want it or not, when they meet you at the very first meeting. And no, I don’t have a problem with overrating people. With some experience in that field you’ll easily recognize all yellow or red lights which appear – you don’t need eliminator questions here. I rather try to be sensitive on specific phrases which can be heard all over the conversation which can be translated into “Don’t hire me.”

    I’m curious if you have your eliminator questions and, if yes, what can be found there.

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

  • Team Management: Find Your Way

    As you probably know, my view on management is rather classic – nothing very far from whatever you can find in a respected canon. I’m against micromanagement, but I try to care about details which are important for people. I try hard to be honest with the team and praise them when they deserved. I believe good performance reviews are important. Just old-school, boring management techniques.

    I believe that’s the way the whole management thing should be done. However it fascinates me every time I read about Bill Gates’ style of management or One Google Management Way.

    Bill, the builder of the greatest company in nineties was considered as bully and the one above isn’t the only example. OK, you can find a lot of bullies in high management around, but somehow many people in Microsoft saw in there a way to improve people’s performance. Everyone had to be superbly prepared, ready to discuss every detail of their opinions and able to resist pressure. Bill’s charisma was essential in building company’s power and his attitude was an integral part of it. You can say it’s weird and it doesn’t work anywhere else, but with Microsoft results speak for themselves.

    When you take current decade and look for its symbol you probably see Google. And you see another strange approach to management. More than 50 people in teams, when 7 people are considered as the optimal group to manage. Famous 20% of time for pet projects. Extremely tough recruitment process with more than 7 meetings on average before hiring. Engineers as sacred cows. All of those, and many more, combined in one place create unique management culture, which is against anything you could learn during an MBA course. And it builds the success of the company.

    I’m impressed. But I’m not going to follow. There are of course some ideas I’d like to implement but, in both scenarios, model as a whole isn’t copyable. As Tom Evslin writes, a barely-graduated hire won’t be as smart as Bill Gates only when he’s as rude. Typical organization won’t achieve a stunning success only when they spend one day in a week for employees’ pet projects.

    I think that organizing a company in a way which allows people to like (just like, nothing more) their employer is tough enough to doom the management to failure in vast majority of cases.

  • Good Enough

    My friend asked me to give an opinion about design of application his company had developed. I took a glimpse on their technical presentation with a lot of screenshots. I must admit my attitude was very positive, whole thing looked professionally. That’s what I told my friend. His answer was a bit surprising as he said he would have worked more on UI design. On the beta stage? It was really good enough. Or even better enough.

    The discussion brought me to think about good enough paradigm in software business. One side believes that if software is good enough the job is done. Another wants to polish all the details until they bring their software into perfection. Although I haven’t seen any statistics about that I believe the former group is more numerous one.

    Software constantly conquers new areas of our life including those where there’s hardly place for good enough believers. Hospitals, planes, cars or military areas. I guess you wouldn’t be happy if your good enough software managing your car brakes crashed. Yet still most software which is developed is not mission-critical products. It just sends e-mails, creates documents, pass information, manage some content, store some data etc. There’s a choice between good enough and close to perfection.

    Personally, I’m a good enough guy. I have just one point here. Costs. Imagine a theoretical scale of perfection of software ranging from 0% to 100%. When you start your development you’re in 0% when you finish you’re somewhere in upper half of the scale. On the beginning improvements are easy. You invite first test UI which looks like it was designed by blind monkey. Then you have first iteration of target UI. It’s a huge improvement, probably a couple of dozens percents on the scale. However, when you’ve already made several iterations with UI and it looks decent the next would be probably making extensive usability testing. It’ll take much more effort than the first steps. Results will be probably much less significant. Few percent if you’re lucky. Next step? Maybe user feedback? You employ a number of people, who deal with all e-mails and phones from users, than trying to find a schema in all that mess, then verifying if accidentally some requests are not exactly opposite to others etc. More effort. More money. Results limited. Maybe another percent earned on the scale.

    The example says about UI, but the rule is general. First performance optimizations will be fast and effective, unless you do them randomly. After some successes they’ll become harder and more costly. On the beginning of stabilization you’ll deal with big numbers of issues vastly improving stability of software. On the end the whole deployment will wait for a single bug fix. Of course that’s not a paradigm – there’re exceptions. Sometimes you can find some easy improvements even when you’re high on the scale, but it shouldn’t happen very often.

    That’s why I’m a “good enough” believer. I don’t refuse to make small improvements, even when users can live without them. They’re welcome as far as they’re cheap. Great example was described by Basecamp team. Those changes are close to border separating good enough from better (hard to say on which side they are), but they were quick and cheap. And I guess the more important improvements were done earlier. If the changes were significantly more expensive I think 37signals would leave it as it was.

    I believe that unless you have much time and money to spend you shouldn’t chase the ideal. There’re more important things to do.

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