Category Archives: team management

Standard

Posted by

Posted on

2016-10-06

Posted under

development, team management

Slow is Smooth, Smooth is Fast

​I think it originally comes from the military, probably the US Navy SEALs, but it’s a popular trope in the racing world, and equally applicable to software development: “slow is smooth, smooth is fast”. It’s intentionally conflicting, but it succinctly states the idea that taking the time to do something well allows you to accomplish the end goal faster overall. 

In autocross, it’s often the run that looks or feels slow that turns out to be fast. There are a few reasons why, and the allegory to development is not hard to see. A lack of excitement or surprises may seem slow, but it’s a sign of tight control and keeping within limits. Smooth, gentle, practiced driver inputs can appear almost casual in their ease. 

On the other hand, the very active driver, who is constantly manipulating the controls and struggling to maintain control and riding the very razor’s edge of traction (or past it) appears to be fast. There’s a lot going on, a lot of action, some squealing and sliding and tire smoke. But the timer doesn’t lie: these runs are not fast. They only appear fast. 

The key is separating being busy from being productive. Not only are they not the same, they’re often in direct opposition to one another. But it may be the busy team that appears productive on the surface. 

The team that fills calendars with meetings and holds war room sessions and works late nights and fixes critical bugs at the last minute looks fast. They can’t waste time on careful thought or refactoring or automation, they’ve got features to ship! But it’s the team that works their eight hours each day with no fuss and no panic, that spends time on automating everything they can, that takes steps to detect and mitigate problems early, that thinks through problems and solutions before writing code, that will accomplish the most at the end of the week. 

Urgency is not a requirement of productivity. Remember: slow is smooth, smooth is fast. 

Standard

Posted by

Posted on

2013-12-18

Posted under

business, development, project management, team management

Engineers, Hours, Perks, and Pride

This started as a Google+ post about an article on getting top engineering talent and got way too long, so I’m posting here instead.

I wholeheartedly agree that 18-hour days are just not sustainable. It might work for a brand-new startup cranking out an initial release, understaffed and desperate to be first to market. But, at that stage, you can expect the kind of passion and dedication from a small team to put in those hours and give up their lives to build something new.

Once you’ve built it, though, the hours become an issue, and the playpen becomes a nuisance. You can’t expect people to work 18-hour days forever, or even 12-hour days. People far smarter than I have posited that the most productive time an intellectual worker can put in on a regular basis is 4 to 6 hours per day; after that, productivity and effectiveness plummet, and it only gets worse the longer it goes on.

Foosball isn’t a magical sigil protecting engineers from burn-out. Paintball with your coworkers isn’t a substitute for drinks with your friends or a night in with your family. An in-house chef sounds great on paper, until you realize that the only reason they’d need to provide breakfast and dinner is if you’re expected to be there basically every waking moment of your day.

Burn-out isn’t the only concern, either. Engineering is both an art and a science, and like any art, it requires inspiration. Inspiration, in turn, requires experience. The same experience, day-in, day-out – interacting with the same people, in the same place, doing the same things – leaves one’s mind stale, devoid of inspiration. Developers get tunnel-vision, and stop bringing new ideas to the table, because they have no source for them. Thinking outside the box isn’t possible if you haven’t been outside the box in months.

Give your people free coffee. Give them lunch. Give them great benefits. Pay them well. Treat them with dignity and respect. Let them go home and have lives. Let them get the most out of their day, both at work and at home. You’ll keep people longer, and those people will be more productive while they’re there. And you’ll attract more mature engineers, who are more likely to stick around rather than hopping to the next hip startup as soon as the mood strikes them.

There’s a certain pride in being up until sunrise cranking out code. There’s a certain macho attitude, a one-upmanship, a competition to see who worked the longest and got the least sleep and still came back the next morning. I worked from 8am until 4am yesterday, and I’m here, see how tough I am? It’s the geek’s equivalent to fitness nuts talking about their morning 10-mile run. The human ego balloons when given the opportunity to endure self-inflicted tortures.

But I’m inclined to prefer an engineer who takes pride in the output, not the struggle to achieve it. I want someone who is stoked that they achieved so much progress, and still left the office at four in the afternoon. Are they slackers, compared to the guy who stayed another twelve hours, glued to his desk? Not if the output is there. It’s the product that matters, and if the product is good, and gets done in time, then I’d rather have the engineer that can get it done without killing themselves in the process.

“I did this really cool thing! I had to work late into the night, but caffeine is all I need to keep me going. I kept having to put in hacks and work-arounds, but the important thing is that it’s done and it works. I’m a coding GOD!” Your typical young, proud engineer. They’re proud of the battle, not the victory; they’re proud of how difficult it was.

“I did this really cool thing! Because I had set myself up well with past code, it was a breeze. I was amazed how little time it took. I’m a coding GOD!” That’s my kind of developer. That’s pride I can agree with. They’re proud because of how easy it was.

This might sound like an unfair comparison at first, but think about it. When you’re on a 20-hour coding bender, you aren’t writing your best code. You’re frantically trying to write working code, because you’re trying to get it done as fast as you can. Every cut corner, every hack, every workaround makes the next task take that much longer. Long hours breed technical debt, and technical debt slows development, and slow development demands longer hours. It’s a vicious cycle that can be extremely difficult to escape, especially once it’s been institutionalized and turned into a badge of honor.

Standard

Posted by

Posted on

2013-04-19

Posted under

team management

Hiring the Best

A commitment to hiring the best requires a significant departure from typical hiring practices, because of the very nature of the beast: the best are rare by definition, and sought-after by nature. That means that when they’re available, you have to hire them. This sounds straightforward enough, but it’s harder to put into practice.

In order to have the best, you have to always be hiring, whether or not you need people. I’m not suggesting you staff up to a thousand employees when you only need ten, but you should be open to the idea of hiring people now up to the number of people you think you’ll need a year or two from now. Allowing moderate over-staffing gives you the flexibility to make an excellent hire when the candidate is available, so that when you really do need them, you aren’t forced to accept less than the best because you’re in a time crunch.

Which brings us to the correlary: when you’re hiring for a specific opening, you have to commit to not hiring people who don’t meet your standards, no matter how badly you need to fill the position. That may mean that while you’re searching for the perfect person, you have to outsource, hire contractors, or hire temporary workers. That may mean that your current employees have to go a little outside their comfort zone and pick up the slack until you can find someone who is a good fit. Just don’t buckle: every time you lower your standards to fill a position, you’re lowering the average quality for your entire operation. Don’t do it.

Both of these ideas – hiring when you don’t need to, and not hiring when you do need to – are somewhat counter-intuitive, can be very difficult to stick to in practice, and can be even more difficult (if not impossible) to convince management of. But if you want to have the best, the only way to get there is by hiring the best when you can, and refusing to hire anyone that doesn’t meet your standards.

It’s also important to understand that candidates who don’t look good on paper may turn out to be rock stars of only you knew you should hire them. If you can possibly manage it, try setting up an apprenticeship program. Take on candidates that seem promising despite being apparently unqualified. Give the paperboy the chance to prove he can write code even though he never went to college. Give the mechanic the opportunity to show he’s a diamond in the rough for your sales department.

The purpose of your apprenticeship program should be genuine apprenticeship – a learning experience for the prospect, and for your team as well. Don’t just treat it as a temp-to-hire situation. Find out how far this person can go if you really back them up and give them the tools to succeed. If it doesn’t work out, cut them loose. If it does work out, guess what? You just picked up an excellent employee that no resume search our recruiter world ever have found, and they’ll likely show more loyalty to your company than an industry veteran ever would.

Standard

Posted by

Posted on

2013-04-01

Posted under

development, programming, team management

Assumptions

We all make assumptions. It’s the only way we can get anything done. If every time you found a bug you started at the iron – testing the CPU to make sure every operation returns an expected result – it’d take you months to troubleshoot the simplest issue. So we make assumptions to save us time, when we know that the likelihood of something being the cause of a problem is far less than the time it would take to verify it.

We also make assumptions out of sheer bloody-mindedness. You can spot these assumptions by phrases like “that couldn’t possibly be it” or “it’s never been a problem before” or “I wrote that code, I know it works”. These are the kinds of assumptions that can get us into trouble, and they’re the exact reason why it’s important to have developers from different backgrounds, with different perspectives, who make different assumptions.

Since we all make assumptions, the best way to challenge those assumptions is to have someone who makes different assumptions look at the issue. They’ll bring their perspective and experience to the matter, challenge your assumptions where they don’t make sense, and make you prove those assumptions to be accurate or not. This stands as a strong incentive to hire a team with diverse backgrounds and areas of expertise. They bring not just talent to your team, but a different perspective.

It’s also a good reason to invest the time in learning different technologies, languages, and development philosophies. Getting outside of your comfort zone can open your eyes to things you might not otherwise have considered, and help you to gain new perspective on your work – helping you to challenge your own assumptions.