A colleague of mine forwarded a link to this blog entry from Ben Horowitz:
http://bhorowitz.com/2011/04/15/peacetime-ceowartime-ceo/
In it, he describes the differences between "wartime CEOs" and "peacetime CEOs" but while I think these distinctions do well describe the difference between types of people, I'm not sure that the situation makes a difference. He notes himself as being a "wartime CEO" and I have to admit I often find myself taking those positions, but I think among his descriptives, he treats a wartime traits as admirable when they often shouldn't.
For example, "Peacetime CEO sets big, hairy audacious goals. Wartime CEO is too busy fighting the enemy to read management books written by consultants who have never managed a fruit stand." I think a CEO in a "wartime" situation (behind the 8-ball) that doesn't set a big, hairy, audacious goal is probably in trouble. I'd argue that figuring out how to become a dominant market force when you're up against competition that is winning the war as the ultimate BHAG. If you're too busy dealing with the tactical engagment, your strategy will fail, if you even have one. How can you "pick your battles" if you don't have a sense of where the strategy is?
Then, "Peacetime CEO has rules like “we’re going to exit all businesses where we’re not number 1 or 2.” Really? I can't imagine a successful CEO who has "rules" like that. They may be strategic decisions, and it may happen, but if a CEO has a rule to exit all businesses they're not winning, they will quickly find themselves not winning anything, regardless of how far ahead they are. Similarly, if you're a wartime CEO and you're not willing to consider dropping a failing effort in order to focus on your goal, you're likely wasting resources and spreading yourself too thin.
I don't think there are peacetime CEOs and wartime CEOs. I think there are CEOs who are never satisified, and there are CEOs who can find themselves content. I think there are CEOs who have different strategies for success, and depending on the circumstances, they may or may not work.
In the immortal words of Edison, (paraphrased), "There are no rules here, we're trying to accomplish something!"
Tuesday, April 19, 2011
Friday, February 18, 2011
Agile Team Roles And Responsibilities
Aotea Studios blog: Agile team: roles and responsibilities - free poster
I saw this posted today on LinkedIn, and think it's a fantastic little chart. I was introduced to the idea of the "agile" process back in 2006, and have seen its good and bad sides.
In the cases where I've seen it crash and burn hard, it's because at least one of those middle roles -- most often the project manager -- was never identified. It seems like all too often, there's an idea that if you have the right process, you don't need anyone to actually manage it. For very small teams of individuals (like founding startup teams) this may be true, although usually, it's just that one person is taking on that role in an ad hoc fashion. Without recognizing that the role is already being filled, if that person leaves, or if the team expands beyond their ability to perform the task of project manager in their "spare cycles", the team starts to falter. The development process drags out as questions go unanswered, people get blocked on requirements that nobody's pursuing answers to, etc. And that uncertainty and confusion, over time, can really eat away at not only your team's productivity, but their morale. I know, I've seen it happen.
In your development team, can you identify who in your team is acting in each of those capacities? It's okay if one person is doing more than one role, but you should be able to identify who is doing each of those jobs. Did you identify someone as the project manager? Do they realize they're the de facto project manager? Does everyone else in the team know who that person is?
First Post!
Every blog has to have a first post, and this one is no different. This blog is about herding cats -- also known as "managing the engineering process".
Let me give you a little background on where I'm coming from...
I've been a software engineer for over 15 years now, and in that time I've worked for about 20+ companies. Not as a contractor or a consultant, but a regular W-2 employee. The first question you're going to ask, I already know, because I hear it every time I talk to someone about a new job lately... "Why? What's wrong with you that you can't stay anywhere?"
The answer tends to be: bad management. There have been a few places I've stuck it out for several years, and when I look back and think about what kept me there so long, I can come up with a number of different factors, but the one that plays the largest is that I was in a position to manage the engineering process, and work with people across the board.
I blame early success. I signed up with a dot-com startup called ONElist back in 1999, a small team, about 20 people when I started, and a year later, we'd merged with our biggest competitor and were then snapped up by Yahoo for half a billion. A lot of those early guys made millions of dollars in that deal. I would've had a nice drop of cash, too, if I'd sold it all before Yahoo's stock tanked a month later. But that got me hooked on startups. It made me want to get in as early as possible.
I bounced a few places right after that (working for large companies after an acquisition has not really worked out well for me thus far) and I ended up at IronPort. Very quickly, I was nominated architect, and it was good. Really bright guys, decent process already in place (still waterfall, but this was in 2002, and nobody's heard of "agile" yet), but I found I was doing a lot more management than development. I was working with the product management team to help crystalize ideas, help prioritize projects, estimate delivery dates, and then working with the engineering team to distribute the work, track progress. I was running bug triages, bringing product, engineering, and QA heads together so we could collaboratively identify where things were going well, where things were going wrong, and making sure everyone knew what the impact of decisions were.
I should've stayed.
Instead, I got swayed by the opportunity to be the first paid engineer at a startup, and I jumped ship. The startup was snapped up in a small acquisition just six months later, which was great, but my equity wasn't all that much to begin with, and once again, I found myself miserable in a large corporate environment.
After that, I went into a bit of a decline. I bounced from startup to startup, looking for satisfying work but always coming up short. In cases where I came in as "the first engineer", I'd often find myself being treated as a contract developer, not as a business partner. Or in cases where I came in as "tech lead" with promises of management, I'd be told later on that they didn't want to "lose my technical abilities by making me a manager". Lots of unkept promises.
I did become CTO for a startup founded by a friend and previous coworker of mine, and that was a terrific experience. I actually got to manage two developers (albeit remotely), and I realized that was where I derived the most satisfaction -- being able to herd the cats and generate terrific results along the way.
That's when I realized, starting my own company, or being in really early, isn't really what it's all about. What it's all about is being able to manage the process, manage the people, and get the best results possible from all the talent you already have available to you.
This blog is about what I've learned, and what I'm continuing to learn, about herding startup cats.
Let me give you a little background on where I'm coming from...
I've been a software engineer for over 15 years now, and in that time I've worked for about 20+ companies. Not as a contractor or a consultant, but a regular W-2 employee. The first question you're going to ask, I already know, because I hear it every time I talk to someone about a new job lately... "Why? What's wrong with you that you can't stay anywhere?"
The answer tends to be: bad management. There have been a few places I've stuck it out for several years, and when I look back and think about what kept me there so long, I can come up with a number of different factors, but the one that plays the largest is that I was in a position to manage the engineering process, and work with people across the board.
I blame early success. I signed up with a dot-com startup called ONElist back in 1999, a small team, about 20 people when I started, and a year later, we'd merged with our biggest competitor and were then snapped up by Yahoo for half a billion. A lot of those early guys made millions of dollars in that deal. I would've had a nice drop of cash, too, if I'd sold it all before Yahoo's stock tanked a month later. But that got me hooked on startups. It made me want to get in as early as possible.
I bounced a few places right after that (working for large companies after an acquisition has not really worked out well for me thus far) and I ended up at IronPort. Very quickly, I was nominated architect, and it was good. Really bright guys, decent process already in place (still waterfall, but this was in 2002, and nobody's heard of "agile" yet), but I found I was doing a lot more management than development. I was working with the product management team to help crystalize ideas, help prioritize projects, estimate delivery dates, and then working with the engineering team to distribute the work, track progress. I was running bug triages, bringing product, engineering, and QA heads together so we could collaboratively identify where things were going well, where things were going wrong, and making sure everyone knew what the impact of decisions were.
I should've stayed.
Instead, I got swayed by the opportunity to be the first paid engineer at a startup, and I jumped ship. The startup was snapped up in a small acquisition just six months later, which was great, but my equity wasn't all that much to begin with, and once again, I found myself miserable in a large corporate environment.
After that, I went into a bit of a decline. I bounced from startup to startup, looking for satisfying work but always coming up short. In cases where I came in as "the first engineer", I'd often find myself being treated as a contract developer, not as a business partner. Or in cases where I came in as "tech lead" with promises of management, I'd be told later on that they didn't want to "lose my technical abilities by making me a manager". Lots of unkept promises.
I did become CTO for a startup founded by a friend and previous coworker of mine, and that was a terrific experience. I actually got to manage two developers (albeit remotely), and I realized that was where I derived the most satisfaction -- being able to herd the cats and generate terrific results along the way.
That's when I realized, starting my own company, or being in really early, isn't really what it's all about. What it's all about is being able to manage the process, manage the people, and get the best results possible from all the talent you already have available to you.
This blog is about what I've learned, and what I'm continuing to learn, about herding startup cats.
Subscribe to:
Comments (Atom)