on the internet:
WTH, companies who do business on the internet?
(Hint: all companies do business on the internet.)
on the internet:
WTH, companies who do business on the internet?
(Hint: all companies do business on the internet.)
CIRREM - 100 kilometers of February slop.
TransIowa v10 – 340 miles of gravel goodness.
Odin’s Revenge - 180-ish miles of gravel, MMRs, and western Nebraska heat.
RAGBRAI - 5 or so days with my kids.
Gravel Worlds - Bikes. Gravel. People who ride bikes on gravel. Sold.
Moose Mountain Marathon - one of the most difficult marathons in the world, according to the brochure. Also a qualifying event for their 50 and 100 mile events. In case you were wondering.
I’ve been turning these thoughts over the last few months as I’ve struggled to figure out where my employer is and where it wants to go; I sketched something like this out on the whiteboard with the rest of my team several weeks ago and we spent several minutes talking through it.
An article in today’s New York Times touched on this topic, prompting me to break out my Sharpie and refine my earlier thoughts.
Fundamentally, what’s missing in a lot of businesses is sharing and alignment of goals. This problem exists to some degree in all organizations, even flat ones, but a top-down organization can suffer immensely from a lack of explicit sharing of goals – and even when goals are shared far and wide, the hard follow-up work to ensure that all employees’ priorities are aligned with those goals often goes un-done.
Allow me to share some diagrams that come dangerously close to over-simplifying the real-world situations we all deal with – but which illustrate problems I’ve seen in every workplace I have been a part of.
In Figure I, you see an organization where the CEO has an idea of where he or she wants to go (a CEO nearly always knows where they want to go!), but hasn’t shared their goal with the rest of the business – not even their top people. Often, what is shared instead is “I need you to do X” rather than “I want this company to be #1 in category Y, and I need your help to make it happen.” The VPs in this case are all working in some fashion, but not cooperating, and their underlings are not contributing anything to the overall movement.
The difference? The VPs have been given a task to do, rather than a goal to accomplish. They haven’t been trusted to use their own expertise – and draw on their teams – to do the right thing. They also haven’t turned around and trusted/empowered their team to help accomplish the goal. As a result, most employees are doing nothing to help “move the puck”.
In Figure II, the VPs have been asked to help accomplish goals, and the direction of their priorities now better aligns with that of the CEO … but the alignment is imperfect, and they still haven’t turned to their teams for help.
Why is this significant? The people below the VPs have no goals; they only have tasks. Without goals, the people are only accomplishing busyness, not movement. The puck may be moving, but it does so despite – not because of – concerted efforts.
In Figure III, we see an organization where the goals have been shared, which is great progress – but the VPs and their teams have not done the (hard) work to expressly align themselves and their work with the larger goals. As a result, individuals and teams may be working the best ways they can think of, but often at cross-angles to, and sometimes against the flow of, the big goals.
Problem? You bet it’s a problem. Why is alignment so important? Any experienced athlete will tell you that publishing a goal – of stating publicly that he or she is going to achieve a PR, win an event, finish a marathon – is an immensely powerful act. Until you do that, you can waffle, worry, and waver; once you’ve said it to another person, it’s out there as a line in the sand.
In Figure IV, once everyone has accepted that they need to do the hard work of aligning what they do, you see that everyone is pushing in the same direction. Rapid progress is now, finally, possible – even likely – as people are busily working toward a common purpose.
Hard? Yes, it is. This is some of the hardest work imaginable. In any organization with a history of people working at odds, this is going to be a hard process. It doesn’t have to be long and drawn out – in fact it should be as quick and decisive as possible – and it may temporarily be very unsettling, as people may choose to part ways rather than fundamentally change their work habits.
In the end, these kinds of changes can be enormously invigorating for a business – in addition to aligning people’s work, the shedding of unproductive energy and an infusion of new blood can be a huge (positive) shock to the system.
I signed up a few weeks ago, despite (or because of) Guitar Ted’s promises of a super-tough 10th edition of the event.
Earlier this month, I participated in the first “Trans Iowa Clinic” – a get-together of cycling-minded folk at (the awesome) Tacopacalypse in Des Moines. The event was fantastic, and I learned a few great things from other riders. I had already been pondering some ways I wanted to improve my bike and gear setup before TIv10, and restoring my gravel bike to its TIv9 state gave me some additional food for thought.
I needed a little extra water at a couple of points (I drink a lot); I just procured a pair of Zefal Magnum bottles for my fork-mounted cages. That should give me an extra 18 oz of water or so compared to the 24 oz bottles I ran on v9. I also made new fork mount adapters that are quite a bit lighter & more pleasing in appearance.
My Schwalbe Marathon tires worked well, but man, they are heavy. I’m going to try some training rides with size-40 Clement MSO‘s. I can shave about a pound off each tire, and at the outside of the wheel, where the difference will be most apparent. Flat resistance will be a key factor in whether I keep the Clements on for the big race.
In the same vein, I could save a bit more weight and also have a more stealth all-black look with a new wheelset I’m collecting parts for. Shimano XT hubs laced to the black Stan’s rims that came stock on my Salsa El Mariachi … hopefully time and budget will permit final assembly prior to April. A big factor will be when Velocity introduces red Dually‘s.
I ran one headlight on my bars and another on a stud mounted to the fork dropout tab; the lower one had a problem with dust obscuring it slightly. I currently have both on my bar now, but it’s a bit too crowded. I’m turning over in my head a plan for a fabrication project to attach a double light mount to the fork crown.
I’ve procured a nice long-sleeved Merino base layer. I also asked for & received a new Endura Pakajak as a birthday gift. Compact, long-sleeved, wind- and waterproof!
Look for some additional info as the Clement’s are procured and put through their paces; I also anticipate a writeup of my attempt at fork crown-mounting my lights.
A small development team can take every phone call and answer every question and discuss every feature and endeavor to make everyone happy by accomodating every request.
Or the team can eschew traditional customer service and be fiercely protective of their time in order to focus on the bigger picture – delivering something new and great.
Each is admirable.
But you must choose one – or you will fail at both.
Links & content from my lightning talk at Windy City Rails 2013:
As a community, software developers have some bad habits that could use changing. We have jobs and lifestyles that are often sedentary, we spend a lot of time indoors, and we don’t usually get enough exercise.
Bike commuting is a way to address all this.
Time spent commuting in the USA in large cities is stunning – sometimes an hour each way, sometimes longer.
I love to ride bikes, so I go by bike. I’ve been doing it year-round since 2007.
Well it’s not even a commute for me anymore. It’s just how I get around. It’s the opportunity to ride my bike twice a day, every day. Sometimes it’s cold, hot, wet, snowy, icy, but if you can do it in a car you can figure it out on a bike.
I think we all know the benefits, but here they are anyway:
Enough about the why – I want to talk a little bit about the what, and the how.
Most people are intimidated by the thought of bike commuting. I get it. Drivers can be jerks; cars are big and they move fast; 10 miles sounds like a lot.
Even bike shops don’t make it easy; they have a reputation as unfriendly, and some are.
But bike commuting is rewarding and actually pretty easy and I want to talk to you about how to get started.
Here’s what you need to buy:
1 – a bike
2 – pedals
(really – they are not included)
A bit more seriously ….
You want a hybrid or “‘cross” (short for “cyclocross”) style bike for commuting. Larger tires, better brakes, and beefier bits that will hold up under the demands of commuting. You do not need a suspension system and you do not need carbon fiber or titanium anything.
I’d recommend a Surly Straggler. Wide range of sizes, big tires, disc brakes, and it comes in sparkly purple or basic black.
You want a set of pedals. If you’re sort of new to cycling, get flat pedals and upgrade later. If you’re already a cyclist, consider Shimano’s “SPD” pedals and shoes – they’re very awesome and very affordable. The PD-A530 pedals and M088 shoes are great choices.
As an aside, SPDs are what are called “clipless” pedals. You might be surprised to learn that you “clip in” to clipless pedals. Naming things is hard outside of software, too.
You want a helmet. All helmets sold in the USA meet the same safety standards, so more money does not buy a safer helment. Buy one that fits you well and you like the look of. Bonus points for picking a color that complements your bike.
You want a lock. Most bike thefts are thefts of convenience – don’t make it convenient. Buy a Knog Party Frank lock in a fun color to match your iPhone 5c.
You want to carry your clothes and lunch. Buy either a backpack or a rack & “pannier” (pronounced pan-year). SwissGear makes great backpacks with laptop sleeves; Surly makes a rack to go with their bikes, and Arkel makes the completely awesome “Commuter” bag.
You want lights. Planet Bike makes affordable lights that are great for being seen – check out the Blaze headlights and Superflash blinkies.
A note on lights – batteries are cheap. Use your lights even when you feel a little silly using your lights. Getting run over will make you feel really silly.
You want fenders. Planet Bike makes very durable, decent-looking plastic black or silver fenders that are easy to install. Go with those.
You want spares. You need a saddle bag with a spare tube, tire levers, a patch kit, a pump, and a “multi tool” (think Swiss Army Knife for bikes). Buy a Banjo Brothers medium seatbag, a tube made for your size of tire with the right kind of valve (Presta is fancy-schmancy; Schrader is like what’s on a car), a Park Tool lever set and patch kit, a Lezyne Pressure Drive pump, and a Crank Brothers M17 tool. Or just carry a phone and call your life partner when something breaks. That should work at least twice.
You want clothes. They’re required by law in most places. This might be the hardest part of the whole deal; a lot of non-cyclists hate the idea of tight Spandex and/or looking like a neon circus clown. Generally any shirt will work – technical fabric is desirable. With shorts or pants, take care, as padding and chafing are considerations. Shorts made for mountain biking these days have a different look from a Tour de France racer, but they still take care of your soft bits.
For cold weather, any coat or jacket will do, though you will find that an insulated one is overkill in most cases. For your legs, there are leg warmers as well as tights, or any pants with velcro straps at your ankles will work. A fleece beanie goes under your helmet and snowboarding mittens keep your fingers warm.
So, that’s eveything you need … but you haven’t left the driveway yet.
Getting started is the hardest part. You have to just do it.
Look around your office and figure out where you can park your bike, and where you can change. Most buildings have somewhere you can lock up inside if you ask. Most bathrooms are up to the task, with some care (have I dipped my shirt sleeve in a toilet? Yes. Yes I have.)
Scout your route ahead of time. A weekend morning is a great time for a practice run, but always be imagining what it will be like with traffic.
Ride on bike paths or lanes where you can. Ride on side streets where you can. When you have to ride on a busy road, take the lane. You are a vehicle, with all the rights and responsibilities that entails. You are more visible, and cars are less likely to squeeze past you, if you have taken the lane.
Be courteous and respectful. Follow traffic laws, and expect that the cars will do the same. DO NOT use your cellphone while riding.
Commit to one day a week at first, and build from there.
Finally, have fun. Once you’ve gotten comfortable with the basic commute, explore a bit. Check out restaurants, bars, and coffee shops on the way. Start to check out cycling events – there are as many ways to enjoy cycling as there are to enjoy coding – not all are hardcore packs of Spandex and sweat turning circles at 35 MPH.
Any questions, ping me: @Capncavedan
See you on the road.
A friend recently completed her first Olympic-distance triathlon. After a period of elation, she was overtaken by a round of self-doubt – perhaps one leg hadn’t been as fast as she wanted, or the overall time – I’m not certain what specifically she was unhappy with. Her tweet read thus: “train my ass off and still suck”
The fact was, she had just finished a pretty grueling event requiring competence in three distinct disciplines and a mastery of gear and nutrition, too. I reminded her of this, but it struck an all-too-familiar chord in my own psyche.
A few years ago, I ran Brew To Brew, a 43 mile ultramarathon in Kansas. I was in no danger of winning, and I walked the last few miles – and while I was proud of myself for finishing, I later “justified” my ability to finish by quoting something I had read about the race: “the easiest ultramarathon in the country.”
This Spring, I took a second crack at Trans Iowa, a 34-hour, 325-mile unsupported bicycle race on gravel roads in Iowa. I’d failed in my first attempt in 2011; this year, I finished with nearly 3 hours to spare. I told myself it was because of the great weather that weekend.
I’ll cite a professional example, too – several years ago I worked as the lead developer on a software system for a nationwide news organization, hurriedly replacing a half-million-dollar commercial system that wasn’t cutting it. It worked, made most people who used it quite happy, and is still in use today, nearly 6 years later. I tell myself it wasn’t the greatest because I was never completely happy with the UI.
Well, that’s all a pile of hooey, really. Unproductive self-doubt.
I finished Brew To Brew because I ran hundreds of miles training, and because on race day I ran for over 8 hours, until my toes bled and my thighs were raw and my legs cramped and I literally could not run another step … and when I couldn’t, I walked to finish it. ”Easiest” or not, it is still a goddamned ultramarathon.
I finished Trans Iowa because I rode my bike thousands of miles through all conditions, because I tried different equipment and food, and then tweaked things and tried again, and again, and again. Because instead of calling for a ride outside a Casey’s store in Gladbrook, I put my shivering, convulsing self back on my bike and rode off into the gathering dark. Because overnight I made myself keep moving 5 miles at a time, all night long. The weather that day was a high near 80 and low of 33 - ”nice”, if you’re sitting by a pool or a roaring fireplace.
As for that software project, well – it was exactly what it needed to be, delivered on time and on budget, and it wasn’t perfect at first but it got pretty close, and in pretty short order.
Stop falling victim to you, your own worst enemy. Look at your accomplishments honestly for what they are, and smile because you did them (you!)
Then ask yourself: what’s next?
Several years ago, I was called into a hush-hush meeting with a couple of mid-level accounting managers and business systems programmers. I wasn’t given much information ahead of time – only that it was about reconciling credit card charges.
I had near-zero experience with accounting or credit card processing at the time, but my manager had recently departed and I had yet to be named his successor, so I had to do. One of the systems my team maintained did generate data that was used downstream to charge credit cards, so I did not initially question my involvement.
There was no clear outline of the problem expressed at any point, and no goals or tasks were defined in that first meeting. I spent much of the time wondering what terms like “general ledger”, “posting”, “booking the charge”, “doing a reconciliation”, and “subaccount code” actually meant.
At the second meeting, I asked what I could do to help. I was tasked with generating a report from the ad entry system detailing dollar amounts of transactions within a specific timeframe; I later provided that, and expected to discuss it in the third meeting.
No such luck. The only thing anyone said about it was that it looked fine. As the meeting wound down, I said “I’m confused; what is the issue we’re trying to solve here?”
One of the accounting managers sighed and said “well, our credit card accounts are off, and we’re trying to figure out why.”
I asked if we knew what specific kinds of charges were wrong, and was told no.
I then asked which direction they were off in, and the manager smiled and exclaimed “the wrong direction!” Everyone chuckled, and the meeting broke up.
Afterwards, I went to my manager and asked to be relieved of the duty of attending these meetings. He asked why. I explained that I had provided a report that seemed to show the errors weren’t coming from “my” system, but that I felt I couldn’t even get a good explanation of the problem – and as a result did not have anything to offer.
He said “well, what would you say the problem is?”
I responded, “I’m told we’re overcharging our customers and we don’t know why.”
He was clearly taken aback, and after a moment said “Dan, are you sure? I was told we are undercharging, and need to collect some lost revenue.”
Obviously I wasn’t sure; my assumption about what the accounting manager had meant by the “wrong” direction was incorrect.
To me, there could have been nothing worse than overcharging a customer. To this accounting manager, however, the world must have looked quite different.
We had some downtime on a server at work over the holiday weekend, and as a result my boss is interested in having that never happen again. He asked about establishing, basically, an on-call system.
It sounds pretty straightforward – just have someone who will keep an eye on things. “Keep the lights on” is how my manager described it. Well, nothing is ever quite that simple, is it?
I’m of two minds on this.
First, obviously, in this day and age it is embarrassing at best to have your website down. I’m an internet software professional and I hate the thought of a down website. So, in that sense, yes, I’m all for having a way to have it not happen or resolve it quickly.
Second, however, I’m a person recovering from over a decade working in the news industry. In terms of on-call and after-hours responsibilities, I was taken advantage of in ways I am still coming to terms with. (That sounds melodramatic, I know – let me buy you a drink & tell you about it, then you tell me if it still sounds that way). One of the reasons I work where I work is that I don’t have to be on call.
I had to deal with on-call issues as an employee on call and later as an on call manager who also had employees on call. A lot of questions came up over the years, along with a lot of intentional and unintentional abuses of the system.
I put down all the questions I could remember, and the list is staggering. It reminds me of Steve Yegge’s seminal blog post on complexity.
There are no right or wrong answers to most of these questions; that is what makes them so hard. That, and the fact that there are nearly 100 of them.
Without further ado:
Are weeknights included in the on-call schedule, or just weekend days?
What about weekend nights? Holidays?
What hours are responses expected?
What is the required response time?
What happens if the response time is not met?
What happens if it’s not met repeatedly – is that a performance issue?
What should the caller do if the phone is not answered? Leave a voicemail?
How quickly should the caller expect a response to a voicemail?
If they’ve called and left a voicemail, are they allowed to call back? How many times?
What should happen if the caller doesn’t ever receive a response to a voicemail?
How long before it’s “ever”?
What should happen if the caller thinks the problem is not being resolved quickly enough?
How quickly is quickly enough?
What should the on-call person do if they can’t resolve the problem on their own?
Escalate? To who? Is there a secondary on-call person?
What if they can’t reach anyone? Are they allowed to keep trying ad infinitum?
How should an issue be reported – can someone call the on-call person, or only email them?
If so, who is allowed to call?
What do we do if someone who is not allowed to call does call?
If not, what do we do when someone does call?
Are callers allowed to attempt to use a home number to reach someone for support?
If not, how should that be handled?
Is only the web site included in this on-call duty? If yes, which web sites? All?
If no, what other systems are supported after hours? Who will troubleshoot those?
How should they be contacted?
Is the on-call person expected to deal with problems during workday as well as during on-call hours?
How often is a person on call?
Does it rotate through the team, i.e. A B C D A B C D … ?
Or is the schedule set for a month or a quarter or a year at a time?
If the schedule is set, when will it be published?
Can scheduled on-call duties be changed or traded? If so, what’s the procedure for doing so?
What if head count changes (up, or down)?
What if a person’s on-call duty falls during a desired vacation?
If multiple vacations conflict with on-call, whose vacation request wins?
Is it first-come first-served, or by seniority?
What if the on-call person uses a sick day – are they still on call?
How will holidays be handled?
If scheduled in advance, how far out will the schedule be available?
If rotated, is it within the year or year over year?
What if the on-call person has no internet access to enable them to solve the issue?
Or are they required to stay at an internet connection, i.e. at home?
If allowed to travel, is the on-call person expected to have a laptop with them at all times?
How far away is considered “travel”?
Is the employee required to have a home internet connection?
Will the company pay for a portion of that connection?
If allowed to travel, what about a mobile internet connection?
Is the on-call person expected to use their personal cell phone for on-call-related communication?
If no, then what? A company phone or pager?
What is the procedure for handing off a company device to the next person?
If yes, then will the company pay for their plan? Or a portion of it?
What if on-call issues cause the person to incur overage charges with their carrier?
If yes, how does the new number get communicated to those who may need to call?
Is on-call duty something the employee gets paid for?
If yes, is that hourly, per incident, or per diem?
If hourly, is it only hours you’re actively solving a problem?
Are there different hourly rates for passive vs active on-call duty?
Can the on-call person flex time spent solving after-hours issues?
How should the time be accounted for?
What hours are “after hours”?
What day and time does on-call duty shift to the next person?
What if that day ond time cannot work for some reason?
If not paid, is on-call duty something the company is allowed to require of existing employees?
If you’re not on call and you get a call anyway, do you get paid for it?
What if it’s call escalated from the on-call person? Do you get paid? Do they?
If you’re on vacation and you get a call, do you get the day back?
Is the on-call person required to log calls? How? What do they need to record?
How soon are they required to record it?
Does the on-call person need to inform the rest of the team or department or their manager during an outage?
After how much time?
What happens if they don’t?
Does the on-call person need to send an update during an outage? Just one? Or how often?
Does the on-call person need to send a summary after an outage? To who? How soon afterward?
Does it need to be reviewed by management before it’s sent?
I grabbed my road bike on the way to work the other day, clipped in and started going before I noticed I was in the big chainring up front – the 52-tooth beast I normally only use on a downhill or when riding in a pack.
I tried to drop down one, but it didn’t go. Since I was running a bit late, I kept going rather than circling back to grab a different bike. Mostly downhill this way anyway.
Over lunch, I found it wasn’t a recalcitrant cable or gummed up mechanical bit, but rather a broken spring. No fix was possible before the (solidly uphill) ride home.
It was a very warm afternoon and I expected to be hating my bike by the time I got home … instead, I tackled the uphill portion handily and arrived at home a bit sweaty but invigorated.
Embrace the constraints.