Pawel Brodzinski on Leadership in Technology

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

Author: Pawel Brodzinski

  • What’s the Use of Wild Guesses Instead of Proper Estimation?

    OK, this one is controversial. Software estimating. How to do it good, or good enough? First of all, when talking about the subject we all can learn a lot from Glen Alleman who bring quite an uncommon perspective to the area as he’s based in industries which tolerate missed deadlines with much less patience than the average.

    Now, what’s the point? If you asked me how software estimating should be done I’d direct you to Steve McConnell book on the subject. Believe me or not, he didn’t write anything good (if anything at all) about role of wild guessing in software estimation. Which doesn’t make me avoiding wild guesses at all times.

    Actually sometimes I make good use of them.

    Now, go flame me.

    What’s the use of wild guesses instead of proper estimation? Wild guesses don’t have to be so wild if you ask a right person. If I ask my development manager how long something would take and it’s a piece of software he’s fairly familiar with in vast majority of cases he’ll come with some guess. It should be reasonable enough to judge whether it’d take 9 months to do the job or rather just a few weeks.

    I don’t consider that as a full-blown estimate. It’s hard to use it as a base to create a schedule but still it’s a valuable feedback to judge whether and when your team is capable to overtake the project or decide if the whole thing is worth further presales effort. If you need to develop a bunch of tools which your competitors already have in their product portfolio chances are good you won’t match their schedules and/or prices. If you add that your team is backed up for the next half of the year it’s probably not worth investing effort to do more than just getting first coarse-grained approximation.

    Yes, every wild guess should be considered very carefully since after all it’s, well, just a wild guess not an estimate done according to rules. However doing proper estimation is quite an effort and sometimes you need something rough but quick instead of exact but demanding.

    And remember: don’t ever, ever allow your wild guesses to be sent to sales department.

  • Role of Leaders in Startups

    Who should be a leader of a startup? An easy question. One of founders. Or even better each of them. They are naturally predestined to leading role. They got the idea. They own the company. They keep all things running.

    Now the more important question: what kind of leaders are they?

    Why is it so important you ask? Well, having a great idea, being a CEO of a company and managing it on a daily basis tells you nothing about leadership. You can end up working either for a great leader or for a sick asshole. No matter which one is true as far as the startup has money leaders won’t change anytime soon.

    Because of a small size of the startup role of leaders is defined a bit differently. Not only they motivate their teams and set up a strategy of the company but they’re also personally responsible for building company culture and enabling company growth.

    In a big organization one asshole doesn’t make much difference – you either work for dozens of them or he’s going to be the only low-performer among great leaders. In a big organizations company culture is already set and it takes a lot of effort and a lot of people to change it (for better or worse). In a big organization one person won’t hamper growth even if that’s CEO who believes leadership is all about yelling at people.

    In a startup one person makes a difference if he leads the company. If he’s a sick weirdo don’t expect healthy atmosphere all over the place. If he makes working for him a hell you won’t see many long-runners in the team as everyone comes and goes as soon as they realize things just won’t change with that kind of boss. In small organizations poor leaders are the main reason why companies suck.

    If you worked for a person who is physically unable to build anything bigger than a couple dozens of people or creating healthy atmosphere at work you exactly know what I’m talking about. Big corporations can be filled with these types and they’ll manage. Startups don’t have luxury to be lead be them.

    That’s a final post of Entreprenurs Time series. I hope you’ve enjoyed it. Please leave your feedback and let me know whether I should post this kind of series in the future.

     

  • Lessons Learned: Startup Failure Part 2

    Last time I shared mistakes we made while working on Overto – startup which was closed down some time ago. Today another part – things we did right and are worth replaying next time I’ll be engaged in a startup.

    Setting up a company behind

    Setting a company, which is quite an effort in Poland, from the very beginning was really a good idea. All founders knew each other well so lack of trust wasn’t the main reason standing behind the decision. We just wanted to give ourselves a bit of motivation making it a real business. However thing we didn’t really plan was that we gained much credibility showing company’s details instead of letting people think the whole thing was created by some student during holidays and won’t be supported in any way in future. Seeing a company behind a service doesn’t guarantee you it won’t die but at least you can be sure someone cares.

    Long discussions before start

    Before launching the project we had very long discussions about what we plan to do and how we want to do it. Of course not every detail was checked but when I compare Overto to other startupish projects I was working on it was really well-thought at the beginning.

    Wide range of roles covered with our experience

    We had really good pack to run an internet service. Development, administration, user support – in all those areas we had experience from the past. There weren’t many things which could have surprise us. We weren’t forced to look for a specialist in any technical aspect of building our application.

    Working in the same place

    For some time we worked in the same building which helped much in decision-making process. We could all meet ad-hoc whenever something important had to be decided. After some time we spread among different places and suddenly we saw how much value was in working in the same office.

    Despite we invested some money to fund the project I don’t treat it as a loss. For experience I gained it was a low price. Another time when I’ll decide to jump to that kind of project chances of success will be bigger.

    First part of lessons learned from startup failure

    Whole Entrepreneurs Time series.

  • Lessons Learned: Startup Failure Part 1

    Some time ago we closed down Overto – startup I was involved in. It was a failure – pretty obvious thing since we’ve closed the service. Since we learn much on our mistakes I think a reliable analysis why the business have failed should be valuable for you. For the beginning things we screwed.

    No one working full time

    From the very beginning we knew none of people engaged is willing to leave their daily jobs to commit fully to the startup. We thought we’d able to run internet service after hours. To some point that was true. As far as nothing bad was happening with the servers and the application it was all fine. We were working on new features when we had enough free time. Problems started when we faced some issues with our infrastructure. We weren’t able to resolve issues on the fly and had several downtimes. You can guess how it influenced user experience. That also backfired on service development since we had to focus on current problems instead of adding new functionalities. Lack of person working full-time and being able to deal with maintenance and bug fixing was the most important reason of failure.

    Catching the market

    That’s partially a consequence of the previous point. Since we spent majority of our limited time on trying to keep the service running we weren’t able to catch the changing market. We needed to cover new areas to move the application to another level but we couldn’t complete ongoing development. The whole project stopped in beta version and for users it didn’t look like anything was about to change.

    Lack of marketing skills

    Thin line between life and death of internet service is a number of users. For the initial period of time the numbers were growing systematically. Then we hit the ceiling of what we could achieve effortlessly. It was a time to do some marketing. Unfortunately no one of us was skilled in that area. Even worse, no one had enough time to fill the gap. That would be another stopper if we dealt with the problems mentioned above.

    Business model

    We hadn’t checked very well a business model we set up on the beginning. We were surprised a couple of our features weren’t as unique as we’d initially thought. Ironically that wasn’t a big problem since we had a bunch of ideas how to adjust the strategy in a new situation. Anyway, you should plan to change your initial business model.

    Screwed chance of selling the business

    After we’d decided we won’t be able to maintain the service in the long run we had a chance to sell it. To make a long story short we screwed negotiations starting with way too high price. We thought more about how much work we put into the project than how much it can be worth for potential buyers. Things are worth as much as one’s willing to pay for them, no matter how long it took you to produce them.

    Waiting too long with final decisions

    I think that one is a bit sentimental. Since the service was our child we were reluctant to make a decision about closing it faster and limit losses. We’ve been tricking ourselves thinking that everything would be fine while we couldn’t get the application back to work properly.

    Second part of lessons learned from startup failure

    Whole Entrepreneurs Time series.

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

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