Referral: The Most Honest Feedback

When I recommend someone to work at my company, it's because I've worked with that person before and I actively want to do so again. That's probably the single-most clear, honest and positive feedback I can give to any previous colleague.

Because, let's face it, everyone has some good qualities and some bad ones. If I say something nice about you, I probably mean it, but it doesn't mean that you don't have bad qualities that counterbalance and overwhelm the positive. Whereas if I refer you to a company at which I work, I've weighed all those factors one against the other, and I've decided that, in the balance, I'd still like to work with you.

If a potential employer asks me about someone with whom I've worked, I'll try and give balanced feedback that includes the things I like about that person's work and things I disliked, or found to be challenges. Most of the time, I'll emphasize the positive, but I'll still try and give something from both sides. I don't want to bad-mouth that person, but I do want the employer to get a sense of what the tradeoff is. That said, if that potential employer isn't my employer, I'm not going to push too hard. Even if I don't want to work with that person again, it doesn't mean that I don't want them to find employment anywhere. In fact, I'd prefer them to find employment elsewhere, because that guarantees they won't seek employment with me.

Most people want to be nice, to be perceived as nice by others and by themselves. And as long as being nice doesn't have a direct cost, most people are willing to do so. So if I've worked with someone, and I don't want to work with that person again, doesn't mean I'm not willing to comment on your good sides (and bad) to a potential employer, and let them make up their own mind. If the employer is using different criteria than I am (or isn't listening very closely to what I say), they may end up wanting to hire that person. So much the better; if there's a fit, that's good for everyone.

But if my employer is asking, I have to ask myself, "Do I want to work with this person?" If the answer is no, then I'm going to do my best to make sure that my employer understands that, even if I use the nicest possible terms to get the job done, "Joe is a great guy; friendly, works hard. I'm not sure he's ever going to be a great programmer. He can get stuff done, but he doesn't seem to really have that design sense that you need to be really good, and I just didn't see any sign that he was getting any better as time went on. I'd probably pass." It's honest, it's direct, and most employers will make the right call if you're being that direct. (I've never worked with a developer named Joe; he's just an example).

If another company were asking about Joe, I might be a little less direct. "Joe is a great guy, friendly, works hard. He wasn't in a senior role when I worked with him; I'm not really sure I can picture him in that role, but I haven't worked with him for a few years, so he may have taken on new responsibilities and skills since I worked with him." This is much more non-committal; a really astute observer might ask some probing questions that I'd answer more or less honestly and get to the heart of the matter, but most people would stop there, and draw their own conclusions.

This is probably why, in part, referred employees tend to be better than the ones that come through regular employment channels. Because the referrers have pre-filtered their past colleagues through the "Do I want to work with that person again?" question, and anyone they refer has passed the test. And despite this fact (or, rather, because of it), it's probably a good idea not to make referral bonuses too high: you don't want to get to the point where the incentive to refer outstrips the incentive to avoid referring people with whom you don't want to work.

So, if I've ever referred you to a company at which I've worked, and they've hired you, take heart, that means I'm willing to work with you again, and said good things about you, and that puts you in the upper tier of people I've worked with. It's probably the most unambiguous feedback you could get from me. And if any of you choose to refer me in the future, I think I'll take that as a high compliment.

The Secret to Life, Career and Happiness

Well, a secret, anyway, maybe not the secret.

Nobody else knows what they're doing either.

Really. That's something I think you need to know. I hope this isn't a surprise most of you, but for those of you whom it is, I'm glad you're here, reading this.

Assuming you're not psychopathically confident, there are probably times in your life or your career when you've felt a little lost, like you weren't sure what to do. This could be when you were trying to ask that cute girl out at the school dance, and you weren't sure how to approach her, or when you're trying to decide between one job and another, or when you're confused about an architectural decision your company has just made.

I get this feeling all the time, I'm not ashamed to tell you. It's probably a daily occurrence. When I was younger, this used to bother me, made me feel like I was clueless where everyone else knew how to navigate their way through life, and I was hapless and insecure.

Over time, I've come to the realization that it's not true. Many, if not most of you, feel confused or lost exactly the same way, probably almost as much as I do. It's part of the human condition, we're all just muddling along.

So, why is this A Secret to Life, Career and Happiness
Well, if you were labouring under the false impression that it was just you, and that the rest of us always know what you're doing, I hope this takes a burden off your shoulders. We don't. In fact, much of the time, we're making it up as we go along.

Interestingly, once you realize this and start to behave accordingly, you'll find that people respond well to you admitting that you don't know what you're doing. In fact, you'll find that admitting you're lost and confused is basically a leadership trait. That may sound odd to some of you, but I'm largely convinced that it's true.

Admit You're Lost at Work
Assume, for instance, that you're working on a project, and the enterprise architect for your enterprisey company has decided that this project Must Be SOA (TM). You don't see any likelihood of other programs interacting with yours, nor is there a technology boundary or multiple user interfaces, so you think to yourself, "Why SOA? It's going to cost us time, but what does it buy us?"

Chances are, some of your coworkers are feeling the same way, but unfortunately, many of them are feeling as I used to: that the reason they're confused is that they don't know what they're talking about, and that the architect and their coworkers are all happy with the decision because they do know what they're talking about.

So if you step up, and say what you're thinking, "Do we really need a service-oriented architecture here?" you'll often find two things are true:

• The people who were feeling the same way are relieved. It becomes clear to them that they're not alone, confused about the architectural choice. They're not alone in their confusion. This is a good feeling, so they're happy.
• Secondly, if your team and enterprisey company are any good, they'll recognize that you're perceptive and analytical, that you ask the right questions and aren't afraid to look stupid in order to advance your understanding and the team's.

These are all good things, and I've found that asking these kinds of questions almost always helps. Usually, either I come away with the understanding I was looking for, or the question helps to drive change. Either way, it's a win.

Don't Swallow that Foot
Don't take this too far; having a question doesn't mean you should be obnoxious. If your company is pursuing a second product line when the first is having some troubles, you could ask, "Our first product line is already failing, so why are we wasting time trying to build another product line that is already failing?" Depending on where you work, this could get you a laugh, a stern conversation or a pink slip.

If you're treading on politically sensitive ground in a politically sensitive company, you could try using yourself as the scapegoat for the question. "I'm sorry, I'm having a little trouble understanding, maybe I missed something. I feel like we're having trouble proving the success of our first product line and now we're going to end up splitting our effort on a new product line. Would it be better to focus all our energies on the first product for the time being?" Most people have a hard time criticizing a question when you start it by implying clearly that you could just be confused or mistaken.

So, be free. Admit that you're lost. And when you're done, come back and tell me how it went.

The Danger of Selling Development Tools

If you have a platform—like Microsoft Windows or Mac OS X operating systems, Java and .NET virtual machines, the iPhone, etc.—and you make development tools for it, I believe you're better off delivering said tools for free.

Now, you can charge for the platform, for the tools, for both, or for neither, but I'd argue that you want the development tools to be as cheap as possible, and, if possible, free. You want to do this because you want to encourage as much development
as you can, and any barrier to development, including the cost of tools, reduces the likelyhood of outside developers building software for your platform. And an active development culture helps to make your platform compelling.

You can't build everything yourself. You can build the premiere applications for your platform, and establish a look and feel, a set of standards that everyone strives for -- Apple does this well, but if you try and lock out the outside developer, you will eventually lose ground to someone else, because an active development community is vibrant. They'll turn out crap, and they'll turn out some weird stuff, and they'll turn out some really great things, and you'll miss out on all of that. I'm biased, because I'm a developer, but even as a consumer, I've shied away from platforms that felt as if they were a development monoculture.

For instance, I've tended to prefer PCs because the Mac development community has often been less vibrant, IMO. In recent years, this has seemed less true.

You also want to make your tools extensible, for the very same reason. If you attempt to build all the tools yourself, you'll lose ground to someone whose tools can be extended by the community, because, again, you can't build all the tools yourself, and if you help developers to help themselves, they'll build an array of supporting tools that make your tool that much more powerful. This leads to more developers using your tools, developing for your platform.

This is, I believe, one of the areas where Microsoft has gone wrong with Visual Studio. They charge for most of the editions of Visual Studio, which encourages some developers to look elsewhere. They offer a free edition, Express, which is a good move, but the free edition cannot be extended (see the TestDriven.NET story for that; I won't attempt to argue who's in the right there, but I do believe it is in Microsoft's interests to allow developers to extend Visual Studio Express).

Now, because Microsoft Windows is one of the most successful platforms on the market, the tool strategy may not hurt them as overtly as it would hurt others, but I do believe that it hampers the adoption of .NET, and reduces the number of potential Windows/ASP.NET programmers.

Desired Traits for a Software Executive

After working with a few technology executives, I've formed a few opinions about what traits are desired.

An Understanding of Software
I've built software at a lot of companies. When the executive level of the company is dominated by executives who don't understand software, the net result is that the company doesn't understand how to build software.

This has a number of potential side effects:

• Unable to Make Tradeoffs: The business is unable to make appropriate decisions in the tradeoffs that are a daily part of building software. Is this release date more important than minor quality issues? Is this blocking defect more important than your scheduled release? Is fixing this issue you've discovered a higher priority than feature X?
• Management by Star Trek: Management decisions are made by people who think that Star Trek is a good model for technology management. "The features you've asked for will take thirty days to build." "Well, you've got ten days!"
• Software is Predictable: The business believes that developing software is a mechanistic, predictable task, and does not react well to the inevitable, that requirements are not clear, that implementation sometimes brings up issues that weren't clear in advance, that we mave to make the kinds of tradeoffs described above.
  
• Emphasis on the Visible: The business puts more emphasis on the visible aspects of software than the invisible ones. "You're not done? But I was playing with the prototype a month ago! What's taking so long?"
  

These kinds of problems are not unique to companies that don't have development-savvy executives, but they're far more common.

A Hands-Off Approach
Of course, having development-savvy executives has its own set of concerns. An executive who has been involved in software development can have trouble keeping his or her hands off the process now that they've moved on up.

This can lead to:

• Micromanagement: Having been involved in the detailed decisions of building software in the past, an executive may want to continue that involvement, even though he or she doesn't have the time to be involved day by day and stay in touch with all the information that leads to those decisions. This can result in what feels like arbitary decisions being made seemingly at random.
  
• Technology Zealotry: Technologists often have favorite technologies. Some have difficulty separating their preferences from merit. When those technologists join the executive, they may try and influence or override technology decisions arbitrarily.
  
• Leading by Design: It's not uncommon for more senior members of a development team to be more involved in the architecture and design of a software platform than junior members. This means that someone who has moved up through software development to executive may be used to leading software teams through architecture and design metaphors. Unfortunately, like micromanagement, this may be done without the time and detailed understanding that project team members have to dedicate to this task, resulting in poor design decisions.
  

These problems are more informed than the problems created by executives that don't understand software, but can be just as damaging.

So, in a technology executive, I'm looking for someone who knows how to code, but is willing not to code.

Do your company's executive team understand software? What traits have you found desirable?

Wireless in Canada

Canada is a country that is so large, but not so populous that its geographically dispersed population has often been quick on the uptake of connecting technologies: broadband internet, wireless phones and devices.

However, when it comes to mobile phones, Canada is not in the forefront, and I blame that firmly on the Carriers: Bell, Telus, Rogers/Fido, etc.

I read about interesting mobile applications daily. Things like GMail and Google Maps on mobile, like Radar or (forgive me) even Twitter. And yet, these don't impact my life, or the life of my friends. Why? Because the Canadian mobile market is all locked up, and those who have the keys are just looking for the leverage to make a little more money.

When infrastructure is new, or difficult to acquire, people seek to control it. Electricity, internet access. These slowly, sometimes very slowly, become commodities, even subsidized, and the community, both business and personal, often benefits from it. While electricity helped to turn on the lights and automate laborious tasks, cheap electricity brought us radio, the telephone, television and the internet. Yes, I admit, it also brought us wall-mounted singing fish and the home shopping channel, but nothing comes without its price.

Similarly, you don't build more bandwidth into the network because people need it for the applications they already have, you build it because they don't even know what they can do with it until they have it: videoconferencing, iptv, voip -- these are technologies that become possible when bandwidth becomes cheap.

This is why I wish that the wireless providers could get it through their dense heads that giving us increased, unfettered access to wireless data and the applications that require that data only makes us their dependent customers. That the idea of paying $100/mo for 250MB of data, 200MB of Data while limiting access to applications and charging monthly fees for access to your phone's GPS capabilities is hurting them as much as it's hurting us.

Get over it. Free us from your mindless restrictions and help us help you make wireless applications and data a ubiquitous part of our daily lives. We'll keep paying you for this stuff, just stop getting in the way.

Musings: Meetings, Lightroom, Netbeans, Ruby

Where does the time go?

Exceptionally busy at work this week, I've been bouncing from meeting to meeting. This is always a tricky balance, as many of these seem to be productive meetings, but at the same time, if all I have time for is meetings, I think the balance has shifted in a bad way.

Spent some more time with Lightroom 1.0 tonight: I've got something like 40Gb of RAW photos on the laptop to organize, process, upload and burn, and Lightroom seems better than most at helping me with an efficient workflow.

Lightroom behaved for me tonight. No sign of the flakiness, shutdowns and other nonsense that plagued me the other night. That's a positive sign. I'll keep my fingers crossed. If I can get through the trial without experiencing more of that, I could be persuaded to enjoy Lightroom.

Trying to clear some photo space so I can download/install Netbeans M7; I've got a minor ruby project I'd like to toy with, and I've been meaning to try the Netbeans/Ruby support, so I can kill two birds with one stone.

How to Recruit Developers Redux: Idealism, Personal Ads and Reddit

First of all: Hi, Reddit. I was surprised when I logged into Google Analytics this evening and saw my graphs spiked heavily today. There's been a fair amount of traffic today, so I wanted to continue the dialogue on some of the points that were raised.

Idealism
Byrne's Eye View argues that my essay gets idealistic as it goes on, that, in essence, most jobs suck, and that there's really nothing to tell.

Fair enough -- there's some merit to that. If everything you could say about your project, your company and your potential employee is, in fact, likely to scare away the candidate, maybe you're better off keeping it generic:

We're a small professional services firm in a tiny, windowless office in a character-free section of the Toronto downtown. Our sales staff has done their usual botched job of overselling the client on features and timelines that we can't possibly deliver, so we're desperately seeking staff with which to pad the project team so that we can show the client how hard we're working. Your coworkers are beaten-down developers that don't have the initiative to look for other employment and contractors who only show up because we're paying their high hourly wage to put up with our bull$h|+. Please apply.

If you feel this way about your company, then I'm going to have to suggest that you work on refining your resume instead of your job posting. That said, I hope that many of you do, in fact, feel there are redeeming qualities to the work, the company and your attitude to employees that just aren't getting out there.

I'm not ducking the point. It's true: the 'sales' job here will be really easy for some companies, and pretty hard for others. But if you focus on what appeals to you, or to the software developers who you employ, and try and make sure that what you post hits those points hard and gives some context, I think you'll find that you're already better off than most job postings that have been generified by recruiters and well-meaning but hapless HR wonks.

Personal Ads
As I was on my commute this morning, after posting, I was thinking how this advice sounds a lot like the kind of advice you might give someone who's preparing a personal ad. That personal ads and job postings aren't entirely dissimilar. Apparently I'm not the only one thinking that, as discipline and punish proved.

That said, I think some personal ad writers and readers thrive on being treated as a commodity, some don't. Personal ads are also, space-limited in ways that job postings aren't. But there are certainly points in common. You'll find that people describe their fondness for candlelit dinners and walks on the beach rather than their skill at romance and cooking. Those are immersive, context-rich ways to get the same content across. I don't think a job posting has to be so oblique, but you do want the posting to resonate with the reader, and dropping the bullet-point skill list in favor of evoking an atmosphere may not be the wrong choice.

In Other News ...
I'm sure there were other comments that I've missed. Feel free to drop me a line, post a comment, or keep the dialogue running.

I've considered, a few times, what it might be like to run a recruiting firm run by developers for development jobs. Could we do a better job of recruiting than recruiters do? I'd be curious to find out, but not curious enough to try.

Access to Capital

According to infectious greed, Canadian startups have pretty good access to capital. Although it looks like 2006 was a better year than 2005.

This is interesting, but I agree that it doesn't necessarily correlate well to dominant, successful startups and a the culture needed to create and sustain these.

Still -- with all that money flying around, does anyone want to offer me some?

How to Recruit Developers: Attractive Job Postings

Most job postings for software development jobs are terrible. Completely unredeemable. In the last ten years, I can count the number of interesting job postings I've seen in Toronto on my hands (and, yes, I have the normal number of fingers).

Your job posting is your first point of contact with potential candidates: your first chance to market yourself, to make your case. This posting can increase the odds that really great software developers will apply to your company, or it can ruin them. If you fail at this (and I can tell you, most companies do), you've seriously damaged your chances at attracting a good-to-great developer.

Who's Watching?
You can group the pool of potential candidates into three broad areas:

• Desperate Job-Hunters
• Job-Hunters
• The Curious

Desperate job-hunters are developers who really, really need a job. They haven't worked in the industry, or they're already between jobs, of they have a job they really hate, writing RPG or MUMPS. You can't drive these people away with a stick. If they're completely unqualified, but think there's any chance in hell of even getting in the front door for an interview, they'll apply.

Job-hunters are looking for a job, but they aren't desperate. These are developers that probably already have a job they can live with, but they're out looking for a different one. They'll read your posting, and if it looks interesting, they'll apply.

The curious are developers who aren't looking for a job, or who tell themselves that they aren't. They've got a job that they're content with, but they're willing to consider an opportunity. They're keeping an eye on the market, or looking for exciting opportunities, or just have a friend who fits one of these three categories. These people are the hardest to attract, and are likely to respond to postings only if they're seriously intriguing.

Desperate job-hunters will track you down. You'll need to work a little to reach the job-hunters, and you'd need to work hard to reach the curious. Interestingly, I suspect that the groups that are harder to reach also contain a higher percentage of good and great developers, because these people generally find good jobs and are able to keep them.

So: here's what you have to gain by writing a great job posting. You'll increase the odds of reaching a wider audience, and more great developers. You can hook them, catch their interest, and maybe, just maybe, get them to apply. Once they apply, your chances of hiring the best candidates go way, way up.

How to Repel Software Developers
Having seen a lot of incredibly bad postings, it's very easy to point out some of the flaws inherent in many job postings:

• Don't Describe The Job
• Don't Describe Yourself
  
• Describe the Candidate as a Commodity
  

If you accept a position, you're going to spend at least a third of your day (almost half the waking hours) at your new job. Most people are going to want to know how they're going to spend that time. The people who don't are probably just looking for a job, any job. Many positions don't describe the job at all. If you want to keep some details private, that's understandable, but share as much as you can. Help your potential new employee be excited about the opportunity in front of him or her.

After the job, the next thing a candidate will want to know is something about the company. You can either try and tell them something about the company in the posting, or direct them to public information about yourself, like a website. Either way, it helps to give context, to give some idea of what you do, what the job's about, and with whom you'll be sharing your work-life.

Finally, it's great if you can tell the candidate what you're looking for without describing them as a commodity. A 'resource', or someone with five bullet-point skill classifications. What kind of person are you looking for? Do they need a passion for development? Does it help to have a background in medicine? Outside interests? These help the candidate to see themselves in the position, rather than see the job as generic.

I've noticed over the years that these flaws are extremely common in recruiter postings. I'm not sure if this is a desire to keep the candidate and the company from finding each other without the recruiter's help, but it's a great way to make a posting seem extremely generic. If you must work with a middleman, see if you can get them to avoid the above flaws. Some sites seem to encourage or accept these more than others. Workpolis.com shows a lot more of these generic postings than monster.ca.

Here are some examples of job postings that exhibit these characteristics: "J2EE Developer", "Java Developer". You don't want your postings to look like these.

What's the Alternative?
So what should you do instead? Describe the job. Describe the company. Explain what you're looking for in a candidate. Make it sound fun, exciting. If you're using neat technology, tell us about it. If you're trying to save the world, include that. Maybe include your answers to the Joel Test. This is your chance, so make it good.

What do good postings look like? This is better. It's not brilliant, but it's better. It talks about the company, the project, the approach. It uses a few selling points about the technology and team.

And what about Tim Fennell, who wants to know what they're doing wrong at the Broad Institute? I don't think the posting's bad. It's a little dense, and it doesn't describe the Broad Institute in detail. It could be presented in a more polished, more accessible manner but the basics are all there.

There are a lot of ways to attract good software developers, but if your posting doesn't get those points across, they may never get far enough to notice.

Couples Therapy for Business and Agile Software Development

Agile software development practices and businesses have been trying to get along for a few years now. In some environments, they're able to find common ground, work together to solve each other's problems, and otherwise form a healthy relationship. In others, they can't even seem to have a conversation without squabbling.

After considering their commonalities and their differences, I propose a form of Couple's Therapy to resolve the differences.

Different Perspectives
It's important to start by recognizing that both the agile developer and the business manager have different perspectives, but that neither party is wrong.

Business managers need to plan: to write budgets, make business plans, and even put out release schedules. These are natural parts of running a business, and they're valuable in their own right. A business that doesn't make budgets and plans isn't likely to have the necessary resources, to meet their client's or market's timelines and is a business that's likely to fail.

On the other hand, an agile developer knows that requirements are almost always unclear, always changing, and that, in fact, the users don't really know what they want. They know the cost of implementation is, at best, a guess, and that the best way to manage this is through some kind of process that balances the constants needed to accomplish goals with the dynamism and need for change that makes agile processes so successful. To manage through constant course-correction rather than trying to predict the future with up-front detailed planning.

These perspectives can seem at odds. An agile developer is wont to say things like, "We don't know when it'll be done" and "I can't tell you what features will make it into that release". These statements can be disturbing to a business manager who is unfamiliar with agile processes or with software development in general.

On the other hand, business managers might say things like, "I need a committed release schedule" or "If you don't tell me how long this will take, I can't make a budget or get resources for this project!" These statements can be disturbing to an agile developer who hasn't learned how to interact with business.

Common Ground
Although these viewpoints focus on different things, there's far more common ground than some people realize. Most business managers have seen or heard enough about software development to know that it's unpredictable, and that software projects are hard to deliver "on time, on budget". A good manager also knows that plans are meant to be changed, that priorities shift constantly, and that nothing can be set in stone.

On the other hand, Agile teams know that they need to have resources, and that resources tend to come from budgets. They have planning metaphors, even if those aren't always the metaphors to which businesses have been accustomed.

Both businesses and agile teams desire successful project completion. Both need to react to change on a regular basis. Both thrive on up-to-date information. Both desire to understand the pace of development, and to make sure that the right features are built in the software at a reasonable cost. These commonalities are more fundamental and more important than the differences.

Working Together
So, having realized that both parties have different, valid perspectives, how can they find ways to work together?

Agile teams can help business to plan, to budget by estimating desired features, working on release plans and otherwise helping the business to understand how long it will take to develop software. As long as both parties understand that plans are subject to change, this planning activity can be valuable.

Agile developers and coaches can also help businesses to understand the positive aspects of agile development: the support of change, the emphasis on delivering value early and frequently and on delivering value through software rather than other artifacts.

Businesses, on the other hand, can accept that up-front detailed requirements and planning for software development is rarely as effective as everyone might desire. That many projects fail, and the ones that do are the ones that refuse to deal with the realities inherent in software development. Business managers can encourage 'up to date' information instead of encouraging an up-front plan that never changes.

Both businesses and developers need to keep the other up-to-date regularly on the factors that affect planning: team velocity, changes in scope, timeline and priorities. Keeping the flow of information open, honest, and frequent is just as important in a business relationship as it is in a personal relationship.

The two teams can then work together on adjusting plans, estimates and schedules based on updated information. This kind of collaboration is possible and normal when agile software development and businesses form and sustain a lasting relationship.

Apple: Drop the DRM

I'm happy to show my support for Apple's/Job's commentary on DRM (although I won't be the only one).

Fundamentally, this is the reason why I've never bought a single song from iTunes, despite owning an iPod and playing much of my music on MP3-capable devices.

Within the last year, there have been at least ten instances where I would have seriously considered making such a purchase, but haven't. Some of those instances, I've decided to purchase a CD instead -- perhaps making as much or more for said record labels. In some of those instances, I've "gone without".

If the labels and artists really want to see the power of digital distribution, they'll need to drop the DRM.

Why So Few Toronto Software Product Companies?

This morning, while reading a blog entry about Pulse by zutubi (via JavaBlogs), I was once again struck by the fact that there are so few software product companies in Toronto. Now, I'm not on the hunt for a job in Australia, so perhaps my perceptions are skewed, but I know a few interesting product companies in Australia even at this distance (zutubi, atlassian, etc.)

And yet, I know so very little about software product companies in Toronto; I know there are a few, but compared to the waves and waves of business / integration software jobs in the Toronto market, these opportunities are practically invisible.

Why is that? What is it about Toronto (or Canada) that seems to result in so few of these startups? Is it that a successful software product born in Toronto is likely to be purchased by a major American firm, and then vanish again? Is it that our entrepreneurs migrate elsewhere (e.g. Silicon Valley?) Do we just have so darned many of the business/integration jobs that people don't bother to start their own companies?

Don't get me wrong -- Toronto's a great place to live and work, but considering that it's software product jobs that really interest me, I just wish there were a few more to choose from.

Team Dynamics, Patterns and Anti-Patterns

I've had the opportunity in my software career to witness two distinct kinds of team dynamics: self-organizing and hierarchical command-and-control. I prefer self-0rganizing by a long margin. This is not to say that it's inherently better (although I have heard interesting arguments about the self-organizing of a military unit in the field), but that I enjoy it more, and find it more productive in the world of creating software.

Command-And-Control Teams
If you and your teammates are largely given separate assignments, work on them individually (or in very small groups) and report status and or defer critical decision to one or a few team leaders, you're probably on a command-and-control team. When your work is late or incorrect, it's between you and your leaders.

On the whole, I find command-and-control teams to be less adaptive, nimble, less reactive to change. Less Agile. This is mostly because a select few are responsible for decision-making, and those few tend to be a bottleneck in the decision-making process.

The command organization is often responsible for both organizing the team internally and co-ordinating the team with all outside influences. They're seen as key stakeholders to involve in both internal and external discussions. This is a lot of responsibility for what is often a very small part of the team. Time management and organization is a constant challenge. Even when the command-structure is well-organized and practices good time management, there's still a bottleneck, and that will cause perceptible delays in decision-making.

When these team leaders are overworked, busy, or not well-suited to detail-oriented leadership, there can be a significant leadership gap. If the team they're leading has been socialized to work within a command-and-control environment, they may not pick up the slack. In these cases, you'll see a well-intentioned team where many things aren't getting done.

It can be easy for team-members on a command-and-control team to slip into dysfunctional habits. There's a whole host of problems here, ranging from 'silos' to "It's not my problem". These boil down to not operating like a team at all. Rather than working together to achieve common team goals, command-and-control teams can break down into competitive self-interested fragments whose primary goal is their own success, sometimes at the deliberate expense of other team members.

Self-Organizing Teams
If you and your team-mates have a are given a set of goals to accomplish, and allowed to structure yourselves as you see fit to accomplish those goals, you may be on a self-organizing team. You'll find that you're committing, as a team to complete team goals, but making local commitments to the team (as a whole) about work that you're taking on yourself. When your work is late or incorrect, you'll resolve it as a team.

Because each team-member is empowered to take on a fair amount of decision-making, this means that the team is adaptive to change, nimble, able to shift resourcing and address issues in a natural, community-oriented manner rather than waiting for a more formal decision-making process.

Giving teams this kind of local autonomy scares the crap out of some business leaders, so it won't work for everyone, but I have tended to find it extremely effective. I've heard it argued that this works best with a small, smart/skilled team. I'm inclined to agree, but I'd also say that's often a factor in the success of any team effort, not just in self-organizing teams building software.

One of the more common anti-patterns in a self-organizing team is slipping back into a command-and-control mindset. Many of us have worked in more hierarchical organizations than we have in self-organizing ones, and it's sometimes easy to let dysfunctionality creep in. These habits are not reinforced by the team structure, but if the mindset of self-organization to accomplish team goals hasn't fully sunk in, some people will slowly slip back into old, bad habits.