Andrew Pollock: [life] Day 294: Babysitting play date, final Prep introductory day and an afternoon play date
Wednesday was yet another full day. It's no wonder I'm feeling so tired, and have a backlog of blogging.
Mel had asked me if I could look after Matthew and Olivia for a couple of hours in the morning. Matthew and Zoe get along fabulously, and the time worked well, so I was happy to help out.
Zoe seems to be going through a bit of a nightmare phase at the moment. I'm sure the heat isn't helping. Zoe woke up with a nightmare about Smudge dying at 2am. Her room was 27°C at the time. 2am seems to be the nightmare time. I got her resettled within about half an hour. I really think I'm going to have to look into air-conditioning her bedroom sooner rather than later.
So I was a bit of a zombie when Mel dropped the kids off at 9am. Fortunately Matthew and Zoe just went off and played together, and Olivia was happy to just hang out with me. She's such a sweet little 2 and a half year old. She kept calling me "Lucy's Dad" or "Sophie's Dad" or something not quite right. It was very cute.
I improvised a bit on the hamburger buns, using a mix of baker's flour and whole-wheat flour and buckwheat. The result still turned out quite satisfactory.
After lunch, Zoe and I headed over to school for the final Prep introductory afternoon. Zoe wanted to walk today. It was a "best of" day for the fine motor skills activities, and Zoe was rather chuffed to get picked as a leader for the gross motor skills activities.
One of the Prep teachers (the one I hope Zoe gets next year) who had remarked on Zoe's timidity on the first day remarked today about what a different girl she was now.
Walking home, there were a ton of ibis on the football field we walk past, so Zoe had a great time running across the field chasing them all. She's getting a lot better about walking longer distances now.
Eva and Layla came over for a play with Tanya in tow after school, and the girls had a fun afternoon. A massive storm rolled in, and so I went and picked up Anshu from the ferry terminal. Once the storm abated, Tanya left with the girls, and then Sarah arrived to pick up Zoe.
Anshu tagged along with me to the P&C meeting. Not the most fun "date night", but I was glad to have another opportunity to attend a P&C meeting before the end of the school year.
Stage one is to turn my modem into just an ADSL endpoint, removing any DHCP, NAT, and PPPoE termination from the device so that it has a single function.
Fortunately my nb604n ADSL modem has a nice easy-to-follow guide for taking it into bridge mode: http://support.netcommwireless.com/sm/videos/nb604n/nb604n-bridge-mode-setup-guide
Now onto greater things!
Let's say you've got an OpenStack build you're getting ready to go live with. Assume also that you're performing some, ahem, robustness testing to see what breaks and prevent as many surprises as possible prior to going into production. OpenStack controller servers are being rebooted all over the shop and during this background chaos, punters are still trying to launch instances with vary degrees of success.
Once everything has settled down, you may find that some lucky punters have deleted the unsuccessful instances but the volumes have been left behind. This isn't initially obvious from the cinder CLI without cross checking with nova:$ cinder list +--------------------------------------+-----------+--------------+------+-------------+-- --------+--------------------------------------+ | ID | Status | Display Name | Size | Volume Type | B ootable | Attached to | +--------------------------------------+-----------+--------------+------+-------------+-- --------+--------------------------------------+ | 3e56985c-541c-4bdd-b437-16b3d96e9932 | in-use | | 3 | block | true | 6e06aa0f-efa7-4730-86df-b32b47e53316 | +--------------------------------------+-----------+--------------+------+-------------+-- --------+--------------------------------------+ $ nova show 6e06aa0f-efa7-4730-86df-b32b47e53316 ERROR (CommandError): No server with a name or ID of '6e06aa0f-efa7-4730-86df-b32b47e53316' exists.
It will manifest itself in Horizon like this:
Now trying to delete this volume is going to fail:$ cinder delete 52aa706df17d-4599-948c-87ae46d945b2 Delete for volume 52aa706d-f17d-4599-948c-87ae46d945b2 failed: Invalid volume: Volume status must be available or error, but current status is: creating (HTTP 400) (Request-ID: req-f45671de-ed43-401c-b818-68e2a9e7d6cb) ERROR: Unable to delete any of the specified volumes.
As will an attempt to detach it from the non-existent instance:$ nova volume-detach 6e06aa0f-efa7-4730-86df-b32b47e53316 093f32f6-66ea-451b-bba6-7ea8604e02c6 ERROR (CommandError): No server with a name or ID of '6e06aa0f-efa7-4730-86df-b32b47e53316' exists.
and no, force-delete does not work either. Here's my approach for resiolving this problem:
SSH onto your MariaDB server for OpenStack and open MariaDB to the cinder database:$ mysql cinder
Unset the attachment in the volumes table by repeating the below command for each volume that requires detaching from a non-existent instance:MariaDB [cinder]> UPDATE volumes SET attach_status='detached', instance_uuid=NULL, \ attach_time=NULL, status="available" WHERE id='3e56985c-541c-4bdd-b437-16b3d96e9932'; Query OK, 1 row affected (0.01 sec) Rows matched: 1 Changed: 1 Warnings: 0
Back on your OpenStack client workstations you should now be able to delete the offending volumes:$ cinder delete 3e56985c-541c-4bdd-b437-16b3d96e9932
Happy housekeeping :-)
AUCKLAND, New Zealand – Friday 21st November 2014 – linux.conf.au 2015 Organisers are proud to announce our funding programme!
InternetNZ Diversity Programme
LCA 2015 and InternetNZ are proud to support diversity. The InternetNZ Diversity Programme is one way we ensure that LCA 2015 continues to be an open and welcoming conference for everyone. Together with InternetNZ this program has been created to assist under-represented delegates who contribute to the Open Source community but, without financial assistance, would not be able to attend LCA 2015.
For more information please see our funding registration page.
linux.conf.au is one of the world's best conferences for free and open source software! The coming linux.conf.au; LCA 2015 will be held at the University of Auckland, New Zealand from Monday 12 January to Saturday 16 January 2015. LCA 2015 will be fun, informal and seriously technical, bringing together Free and Open Source developers, users and community champions from around the world. LCA 2015 is the third time linux.conf.au has been held in New Zealand. The first was in Dunedin in 2006 and the second was in Wellington in 2010.
For more information please visit our websiteAbout Linux Australia
Linux Australia is the peak body for Linux User Groups (LUGs) around Australia, and as such represents approximately 5000 Australian Linux users and developers. Linux Australia facilitates the organisation of this international Free Software conference in a different Australasian city each year.
For more information see: http://www.linux.org.au/Emperor Penguin Sponsors
LCA 2015 is proud to acknowledge the support of our Emperor Penguin Sponsors, Catalyst IT, HP and IBM, and our diversity sponsor Internet NZ.
For more information about our sponsors click below -
I probably don’t have to tell you that pricing is slippery business. It requires a lot of perspective, experience, and luck (read: trial and error). There are a number of ways we can correlate monetary value to what we do, and each has its pros and cons.
It may seem at first glance that pricing models begin and end in the proposal phase of a project. That pricing is simply a business negotiation. But whether we’re talking about design, development, or business methodologies, our processes affect our motivations, and influence outcomes—often throughout the entire project. We’ll be examining both client and agency motivations in our comparisons of pricing models, so you can judge whether those motivations will help you make better work with your clients.
All of these pricing systems operate with the same set of variables: price, time, and scope. In some systems, such as hourly pricing, variables are directly dependent on each other (e.g. if I work an hour, I get paid my hourly rate, and deliver an hour’s worth of work). In others, like fixed price and value pricing, the relationships can be nonlinear (eg. I am paid a sum of money to achieve some set of results, regardless of how much time I spend doing it).
These dependencies tend to define each system’s inherent risk and potential for profit. And all the differences can get pretty bewildering. One person’s experience is hardly enough to understand them all well, so I’ve enlisted some friends from web agencies of various sizes to chime in about how they make things work.
As with most things in life, there’s no perfect solution. But if you want to get paid, you have to do something! Enough gum-flapping, let’s take a look at some of the different ways that people are pricing web projects.Fixed price
With fixed-price projects, you and the client agree up front on a cost for the entirety of the project. Many folks arrive at this number by estimating how many hours they think it would take them to do the project, and multiplying that by an hourly rate. That cost will be what the client pays, regardless of actual hours spent.Client motivation
When the price of a project is fixed, the variable tends to become scope of work. This encourages clients to push for the maximum deliverables they can get for that cost. This can be addressed to a degree by agreeing on a time limit for the project, which keeps requests and scope changes from occurring in perpetuity.Agency motivation
On the agency side, your motivation is to be as efficient as possible to maximize the results while reducing time spent. Less time + more money = greater profit.Pros
Because you know exactly how much money is coming in, revenue is fairly predictable. And since revenue isn’t tied to the time you spend, profit is potentially greater than with a time-based model—especially when the cost is high and the timeline is short.Cons
The same factors that provide the possibility of greater profit create the potential for greater loss. Defining exactly what a client will receive for their money becomes a high priority—and defining things well can be harder than it sounds.
Eileen Webb, Director of Strategy and Livestock at webmeadow, provides some insight into how she defines scope with her clients:
I like to define the project boundaries clearly by having a “What’s Not Included” section. This may be a listing of services you don’t offer, like SEO or hosting. It’s also a place to list features that you and the client discussed but decided against for this budget or phase. Defining what falls outside the scope is a good way to help everyone agree on what falls in it.
Now, getting to this definition in the first place is—I probably don’t need to tell you—hard work. And hard work is something you should get paid for. Starting out with an initial discovery engagement is something nearly any project can benefit from, but for fixed-price projects it can be invaluable.
Resourcing for a fixed-price project can also be hard to estimate, since scope is not necessarily easy to equate to effort and person-hours needed.
But the primary difficulty with fixed price may be the innate conflict between a client’s motivation to ask for more, and an agency’s motivation to provide less. For a fixed-price project to be successful, this must be addressed clearly from the beginning. Remember that scope discussions are just that: discussions. More isn’t always better, and it’s our job to help keep everyone on the project focused on successful outcomes, not just greater quantities of deliverables.Hourly
At its core, hourly pricing is pretty simple: you work an hour, you get paid for an hour. Hourly, like all time-based pricing, suggests that what’s being paid for is less a product than a service. You’re being paid for your time and expertise, rather than a particular deliverable. Rob Harr, Technical Director at Sparkbox, explains how hourly projects tend to work for them:
Since everything we do is hourly, the end of the job is when the client says we are done. This sometimes happens when there is still approved budget left, and other times when the budget is completely gone. Often times our clients come back for additional SOW’s to continue the work on the original project.Client motivation
With hourly, clients are encouraged only to ask for work when that work appears to be worth the hourly cost. Since there’s no package deal, for each feature request or task they can ask themselves, “Is this worth spending my money on, or would I rather save it for something else?”
Project delays are not a financial concern for the client, as no money is spent during this time.Agency motivation
The more an agency works, the more they get paid. In its purest form, this leads to the agency simply wanting to work as much as possible. This can be limited by a few factors, including a budget cap, or not-to-exceed, on the project.
Project delays are a major concern for the agency, as they’ll lose revenue during these periods.Pros
Every hour a team member spends is paid for, so the risk of this model is very low. If a company is struggling with profitability, I’ve personally found that this is a great way to get back on track.Cons
Unlike fixed-price models, you can only earn as much as you can work. This means that profit maxes out fairly quickly, and can only be increased by increasing hourly rate (which can only go as high as the market will bear), or expanding the team size.
Because the agency is only paid when they work, this also means a big imbalance in how project delays affect both sides. Thus clients that aren’t in a big hurry to complete work—or have inefficient decision-making structures—may not worry about long delays that leave the agency financially vulnerable. This can be addressed somewhat by having conditions about what happens during delays (the client pays some sort of fee, or the project becomes disproportionately delayed so the agency can take on new work to fill the gap in their schedule). Even with these measures, however, delays will cause some kind of financial loss to the agency.Weekly or monthly
Though similar to hourly in many ways, charging by weekly or monthly blocks has some distinct differences. With these models, the cost assumes that people work a certain number of hours per week or month, and the client is billed for the equivalent number of hours, regardless of whether or not actual hours spent were more or less than assumed.
Trent Walton, founder of Paravel, explains why they like this approach:
Most of our clients operate in two-week or month-long sprints. For many projects, we’ll quote chunks of weeks or months to match. This alignment seems to make sense for both parties, and makes estimating scope and cost much easier.Client motivation
Clients tend to want the agency to work as much as possible during the time period to get the maximum amount of work or value. This can be curbed by having a maximum number of hours per week that will be spent, or understanding limitations like no nights or weekends. Related to this, it’s in the client’s best interest to not let project work succumb to delays.Agency motivation
On the agency side, we’re encouraged to be as efficient as possible to maximize results each week, while spending fewer hours accomplishing those tasks. As long as the results are comparable to what’s expected, this motivation tends not to result in conflict.
At Bearded we’ve found that with weekly projects we spend, on average, the number of hours we bill for. Some weeks a little more, some a little less. But it seems to all come out in the wash.Pros
Knowing that a time period is booked and paid for makes resourcing simple, and keeps the financial risk very low.
Because the agency is paid the same amount every week or month, clients will tend to do whatever’s necessary to avoid any delays that are in their control. This completely removes the risk of the agency losing money when projects are held up, but also requires the agency to use a process that discourages delays. For instance, at Bearded, we’ve moved to a process that uses smaller, more frequent deliverables, so we can continue working while awaiting client feedback.Cons
Similar to hourly, the agency’s profit is capped at the weekly or monthly rate they charge. To make more revenue they’ll need to charge more for the same amount of work, or hire more people.Value
Value pricing is a method wherein the cost of the project is derived from the client’s perception of the value of the work. That cost may be a fixed price, or it may be a price that factors in payment based on the effect the work has (something closer to a royalty system).
Dan Mall, founder of SuperFriendly, explains his take on value pricing using a fixed cost:
I use a combination of value pricing with a little of cost-plus. I try my best to search for and talk about value before we get to dollar amounts. When my customers are able to make a fully informed price/value assessment, the need to justify prices has already been done, so I rarely have to defend my prices.
Dan’s approach suggests that if a company stands to gain, say, millions of dollars from the work you do, then it doesn’t make sense for you to merely charge a few thousand. The value of your work to the company needs to be factored in, resulting in a proportionally larger fixed cost.
Other takes on value pricing tie the cost of the project directly to the results of the work. This can be assessed using whatever metrics you agree on, such as changes in revenue, site traffic, or user acquisitions. This sort of value pricing lends itself to being used as an add-on to other systems; it could augment an hourly agreement just as easily as a fixed price one.
It’s worth noting that none of the folks I talked to for this article have done this in practice, but the general approach is outlined in Jason Blumer’s article Pricing Strategy for Creatives.Client motivation
This depends primarily on the other system that you’re using in conjunction with value pricing. However, if a client recognizes the tangible gain they expect from the outset, this will tend to focus their attention on how the work will influence those outcomes.Agency motivation
When payment is tied to metrics, the focus for the agency will be on work that they believe will positively affect those metrics. Like client motivations, an agency’s other motivations tend to be the same as the other system this is based on (fixed, hourly, weekly, or monthly).Pros
Because of the nonlinear relationship between labor and revenue, this approach has the highest potential for profit. And as long as the base pricing is reasonable, it can also have very low financial risk.Cons
Since value pricing is potentially connected to things outside your control, it’s also potentially complicated and unpredictable. If revenue is based on future performance metrics, then accurately determining what you’re owed requires knowledge of those metrics, and likely a little legwork on your part. There’s also a certain amount of risk in delaying that payment until a future date, and having its existence in question altogether. As long as the base pricing you use is enough to sustain the business on its own, that risk seems less worrisome.
With value pricing, there’s also the need to assess the value of the work before agreeing on a price. Which is why—as with fixed-price projects—value-pricing projects often work well as a followup to an initial discovery engagement.
Patty Toland and Todd Parker, partners and co-founders of Filament Group, explain their approach to an initial engagement:
Most of the projects we engage in with clients involve fairly large-scale system design, much of which will be defined in detail over months. We provide high-level overall estimates of effort, time and cost based on our prior project work so they can get a sense of the overall potential commitment they’re looking at.
If those estimates work with their goals, schedule and budget, we then agree to an initial engagement to set a direction, establish our working relationship, and create some tangible deliverables.
With that initial engagement, we estimate the total amount of time in person-days we plan to spend to get to that (final) deliverable, and calculate the cost based on a standard hourly rate.It depends
So what’s the best approach for you? Blimey, it depends! I’ve talked with many very smart, successful people that use very different takes on various approaches. Each approach has its benefits and its traps to watch for, and each seems to work better or worse for people depending on their personalities, predilections, and other working processes.
Ultimately it’s up to you. Your hunches, experience, and probably a little experimentation will help you decide which method makes the most sense for you, your team, and your clients. But don’t be surprised if once you find a good system, you end up changing it down the road. As a business grows and evolves, the systems that work for it can, too.
Now that we’ve talked about pricing methods, we’re ready to move on to something everyone’s really bad at: estimating! Stay tuned for that in part three of this series.
Unless you’ve been living under a firewalled rock, you know that IPv6 is coming. There’s also a good chance that you’ve heard that IPv6 doesn’t have NAT. Or, if you pay close attention to the minutiae of IPv6 development, you’ve heard that IPv6 does have NAT, but you don’t have to (and shouldn’t) use it.
So let’s say we’ll skip NAT for IPv6. Fair enough. However, let’s say you have this use case:
A bunch of containers that need Internet access…
That are running in a VM…
On your laptop…
Behind your home router!
For IPv4, you’d just layer on the NAT, right? While SIP and IPsec might have kittens trying to work through three layers of NAT, for most things it’ll Just Work.
In the Grand Future of IPv6, without NAT, how the hell do you make that happen? The answer is “Prefix Delegation”, which allows routers to “delegate” management of a chunk of address space to downstream routers, and allow those downstream routers to, in turn, delegate pieces of that chunk to downstream routers.
In the case of our not-so-hypothetical containers-in-VM-on-laptop-at-home scenario, it would look like this:
My “border router” (a DNS-323 running Debian) asks my ISP for a delegated prefix, using DHCPv6. The ISP delegates a /561. One /64 out of that is allocated to the network directly attached to the internal interface, and the rest goes into “the pool”, as /60 blocks (so I’ve got 15 of them to delegate, if required).
My laptop gets an address on the LAN between itself and the DNS-323 via stateless auto-addressing (“SLAAC”). It also uses DHCPv6 to request one of the /60 blocks from the DNS-323. The laptop puts one /64 from that block as the address space for the “virtual LAN” (actually a Linux bridge) that connects the laptop to all my VMs, and puts the other 15 /64 blocks into a pool for delegation.
The VM that will be running the set of containers under test gets an address on the “all VMs virtual LAN” via SLAAC, and then requests a delegated /64 to use for the “all containers virtual LAN” (another bridge, this one running on the VM itself) that the containers will each connect to themselves.
Now, almost all of this Just Works. The current releases of ISC DHCP support prefix delegation just fine, and a bit of shell script plumbing between the client and server seals the deal – the client needs to rewrite the server’s config file to tell it the netblock from which it can delegate.
Except for one teensy, tiny problem – routing. When the DHCP server delegates a netblock to a particular machine, the routing table needs to get updated so that packets going to that netblock actually get sent to the machine the netblock was delegated to. Without that, traffic destined for the containers (or the VM) won’t actually make it to its destination, and a one-way Internet connection isn’t a whole lot of use.
I cannot understand why this problem hasn’t been tripped over before. It’s absolutely fundamental to the correct operation of the delegation system. Some people advocate running a dynamic routing protocol, but that’s a sledgehammer to crack a nut if ever I saw one.
Actually, I know this problem has been tripped over before, by OpenWrt. Their solution, however, was to use a PHP script to scan logfiles and add routes. Suffice it to say, that wasn’t an option I was keen on exploring.
Instead, I decided to patch ISC DHCP so that the server can run an external script to add the necessary routes, and perhaps modify firewall rules – and also to reverse the process when the delegation is released (or expired). If anyone else wants to play around with it, I’ve put it up on Github. I don’t make any promises that it’s the right way to do it, necessarily, but it works, and the script I’ve added in contrib/prefix-delegation-routing.rb shows how it can be used to good effect. By the way, if anyone knows how pull requests work over at ISC, drop me a line. From the look of their website, they don’t appear to accept (or at least encourage) external contributions.
So, that’s one small patch for DHCP, one giant leap for my home network.
The standard recommendation is for ISPs to delegate each end-user customer a /48 (giving 65,536 /64 networks); my ISP is being a little conservative in “only” giving me 256 /64s. It works fine for my purposes, but if you’re an ISP getting set for deploying IPv6, make life easy on your customers and give them a /48. ↩
If you’re someone who doesn’t like Debian’s policy of automatically starting on install (or its heinous cousin, the RUN or ENABLE variable in /etc/default/<service>), then running an init system other than systemd should work out nicely.
DrupalSouth is the biggest Drupal gathering in the Antipodes.
We'll be at the Melbourne Convention and Exhibition Centre over three days in early March 2015. March 5-7 to be exact.
Find out more at the website
The call for sessions is open, and we're trying hard to get the word out wide and far, to whisper in new ears, and encourage people of all sorts to share their ideas for sessions so we can create a truly wonderful, inspiring, engaging and fun program for this conference!
For those who may not know, Drupal is an open source content management system. It's used by people and organisations all around the world, for all sorts of web sites. It's also being used as back end application framework for mobile apps! It's amazing what Drupal can do.
Drupal events are the heart and soul of the community that makes Drupal. Bringing people together drives the project forward, and forges friendships.
But we're also part of the wider web. So we want to hear from all sorts of web specialists, not just Drupalists.
Please, submit a session, or simply help us spread the word. The deadline is looming and won't be extended. Get that proposal in by 30 November 2014. https://melbourne2015.drupal.org.au/program/session-submission
1:20pm Thursday 15th January 2015
Andrew McDonnell is a professional software engineer with two decades experience, having spent many years before that hacking code after receiving a Commodore 64 for Christmas at age 12. He has significant experience programming in C++, Java and Python and a multitude of scripting languages. Outside of family and work he sometimes has time to play with his collection of 8-bit and PC/XT-vintage computers; computing and electronics has always been his passion. He intermittently maintains a blog at http://blog.oldcomputerjunk.net sometimes posting how he solved a problem in the hope it may be useful to someone else.
Jim Cheetham OneRNG - An Open and Verifiable hardware random number generator
1:20pm Thursday 15th January 2015
Jim works in Information Security, and has a long background in Unix/Linux and Open Source/Free software systems.
A note from the editors: We’re pleased to share an excerpt from Jenny Lam and Hillel Cooperman’s new book Making Things Special, Tech Design Leadership from the Trenches, available now. A List Apart readers can also enter to win a copy of the book.
Hierarchical organizations large and small are rife with politics. In fact, the smaller the stakes, the more vicious they can be. Political organizations are ones where what things look like are just as, or more, important as what you actually do. Dealing with perceptions as well as ego and insecurity is part of dealing with human beings. This is who we are. And as soon as we create situations where there are winners and losers we create politics. And fighting. In some organizations, regardless of how brilliant your design may be, the politics will kill your plans before they have a chance to really blossom. And that’s a shame.
The single most important thing you can understand about navigating the gauntlet of organizational politics is the relative risks of saying no versus yes. Your job, your dream, your passion is to say “yes.” Yes to your product vision. Yes to your design. Yes to delighting customers. But the road is littered with opponents. These are people who will raise concerns about your proposals, reasonable sounding concerns. Concerns that may or may not be genuine. Maybe they’re good thoughts to consider that have been offered in good faith, and maybe they’re just obstacles designed to trip you up and damage you as a competitor in the organization. If you suspect an opponent’s motivations are personal, you’ll never prove it. That only happens in the movies. In effect, their motivations are irrelevant. Genuine or jerky, your only remaining option is to deal with their issues at face value.
Before we answer, let’s pause for an anecdote.
Years ago we worked on one of two teams in the same company that worked on competing projects. This happens often. The company’s leadership hopes competition fosters innovation, and people bringing forth their best ideas. The other team was huge and had been working on their project for years. There were smart and talented people on that team doing good work. They even had good design talent, but the team wasn’t design driven. They were technology driven. This is not to say that they didn’t think about customers. They did. It’s just that the high order bit was their technology choice, and then they did their best to design around those choices.
Our team was small. We had decent ideas and were design led. Our team fashioned a high-fidelity prototype that illustrated our ideas. It was on rails, a glorified slide show. And it was gorgeous. The other team had code. We had beautiful images that moved.
As things came to a head politically, we finally revealed our design to the other team. After the presentation, they looked like they’d been punched in the stomach. Even though they had code, we just had a better story. We had something inspiring. Their stuff was flat. And boring. Literally and metaphorically. And even though they were creative and smart, the genetics of their team had led them down an uninspiring path. They knew it. And so did the execs who saw both teams’ work.
Within a week those execs tried to merge our teams. And when it was clear that we were culturally incompatible, their project was killed. Was our design work solely responsible for the end of their project? No. Was it one of the things that sent them over the edge? Without a doubt.
Now let’s return to our discussion of how you can deal with the people who oppose your plans in your organization. Your first choice is to use the logic of your arguments, your personal charm, and maybe a little horse trading to get those folks on board. And in many cases that works. It’s always your best option. We’re big fans of working together harmoniously. But the larger the organization (and it doesn’t have to be all that large) the higher the odds that there will be some people where reasoned discussion and collaboration doesn’t work. Ever.
Remember, the political economics of saying “no” in large organizations are so much better than saying “yes.” Saying “no” costs essentially nothing. You don’t need to prove anything. You’ll almost never be proven wrong for saying no. And the optics are great too. The person saying “yes” looks overly enthusiastic, while the person saying “no” in reasonable tones sounds like the grownup. The naysayer just has to raise reasonable doubt to save the company from wasting time and money on some “foolish and poorly thought out initiative.” However, saying “yes” is costly. You’re putting yourself out on a limb. You’re being specific. You’re opening yourself up to attack. You’re trying to do something.
As a user experience design leader you have a secret advantage. It’s the thing that often overcomes every opponent, every craven naysayer. It’s the High Fidelity Visualization.
What is the High Fidelity Visualization? It could be anything from a series of beautiful UI mockups, to a user experience prototype on rails, to a freeform prototype that the audience can try themselves, to a beautifully produced video showing customers using the prototype.
There will always be “no” people. But “no” people rarely have counterproposals. And when they do, they’re usually vague or a set of yawn-inducing PowerPoint bullets. By definition, they don’t want to be out on a limb or they’d be subject to attack. So they keep things light on details. But when you show up with a High Fidelity Visualization, if you’ve done your job, and told a great story, everyone else in the room will fall in love with your plan. Decision makers will get excited. They’ll start defending your ideas against the naysayers. Emotion motivates them to become advocates for your plan, your story. And this is a good thing.
But take note, we liken these visualizations to nuclear weapons. They’re incredibly powerful tools and can cause collateral damage. You’ve got to get the dosage just right. Sometimes you can do such a good job getting your company’s leadership on board with your ideas that now they bother you every week to find out why the product isn’t done yet. After all, that prototype looked essentially ready to ship, and you didn’t spend a lot of time in your pitch meeting talking about the smoke and mirrors you used to put it together.
The point is this: with a beautifully executed High Fidelity Visualization that sets the right tone, you can neutralize the people in your organization who love to say “no.” This is your secret advantage as someone with vision, an ability to visualize your plan and bring it to life in people’s imagination, and the leadership skills to deliver on that vision. Tell the right story with your execution here and anyone who’s getting in your way will fall by the wayside.
And for those of you who feel this is militaristic in tone, you’re right. Hierarchical organizations with more than ten people on the team invariably have a representative population of personality types — including people who will get in your way. If you really want to make something special and deliver it to customers, then you need to get the doubters on board or run them over. Partnering with the doubters is always preferable as long as it’s not at the expense of your ideas. But unfortunately, it’s not always possible. It’s not personal. It’s not about being a jerk. It’s not about beating your chest. It’s about making something great. And if you’re in an organization where people with limited vision and possibly political aims are forever stopping you from delivering something wonderful, you need to arm yourself and fight. Spending your time arguing endlessly with people so you can deliver a watered-down version of the great thing that resides in your head is a waste of your time.
How do you know which feedback is killing your vision and which is making it better? Listen to everyone, open your mind, but trust your instincts. If you stick to your guns and fail, at least you’ll learn something. If you turn your ideas into some sort of compromise mishmash and you fail, you’ll never know exactly what caused the failure and you truly will have wasted your time.
Good luck soldier.
Consider the following 6 data structures:
- Hash table
- Doubly-linked list
- Binary search tree
- Directed acyclic graph
Using these as the subject matter, construct 6 really good puns.
After receiving a range of questions from different sources, I was unsure which to answer first — I was stack as to where to begin. And so because this was the last question that I received, it became the first that I answered.
Don’t get me wrong — I did appreciate the question. The capacity of my gratitude is, theoretically, unbounded. Thanqueue.
We have a cuckoo aviary. I keyp a record of each birth in a hatch table.
I noticed that I was leaning to one side. I spoke to a physician about it — he told me I was overweight because I was eating too much bread. My list, it seems, is linked to my dough-belly.
On a school trip to a pickle factory, my daughter went missing. I was able to climb the brinery search tree and spot her, though it took longer than I had hoped due to my poor balance.
While out walking, I deflected a cyclist’s gaffe, knocking him aside as he rode the wrong way down a one-way street. I looked down my nose at him and gave a topological snort to help him on his way.
The reader may decide whether the answers satisfy the requirements of the question.
Digital technology is a disruptive force driving unforeseen change in societies, economies and businesses throughout the world. Susan Greenfield proposes that our brains are also changing in response.
What do these unprecedented changes mean for the future education of our children and young people? What do they mean for their education now? What can teachers and parents learn from neuroscience that will help them prepare children for life in the 21st Century?
3:40pm Wednesday 14th January 2015
Katie is a part of the Engineering team at Anchor Systems, working to improve *all* the things. She has a history of enterprise development and Windows system administration, but has been successfully converted to the ways of the penguin in recent years.
Andrew Bartlett Pushing users into the pit of success - stories from the Samba 3 -> Samba 4 transition
23:40pm Thursday 15th January 2015
Andrew Bartlett is a Samba Developer currently employed by Catalyst in Wellington, NZ. Andrew has been developing Samba since 2001, and has had a strong focus on the Active Directory DC project for the past decade or so. He is passionate about authentication systems and making Samba a great, interoperable alternative to the dominant implementation from Microsoft.
For more information on Andrew and his presentation, see here.
Imagine this scenario. You’re hired to design a product that has a guaranteed audience of 50,000 users, right out of the gate. Your clients have a dedicated support staff with a completely predictable technology stack. Best of all, your work directly improves the quality of your users’ lives.
That’s enterprise UX.
Yes, those 50,000 people use your software because they don’t have a choice. And sure, that completely predictable technology stack is ten years out-of-date. But, despite its quirks, doing UX work for enterprise clients is an opportunity to spread good design to the industries that need it most.
Enterprise UX is a catch-all term for work done for internal tools—software that’s used by employees, not consumers. Examples include:
- HR portals
- Inventory tracking apps
- Content management systems
- Intranet sites
- Proprietary enterprise software
Since switching from working with smaller clients to tackling the problems of the Fortune 500, I’ve fielded a lot of questions from designers mystified by my decision. Why choose to specialize in enterprise design when you could do more interesting work in leaner, more agile, t-shirt-friendly companies? Isn’t big business antithetical to design culture?
The answer is: yes, often. Working with enterprise clients can be an exercise in frustration, filled with endless meetings and labyrinthine bureaucracy. It can also be immensely rewarding, with unique challenges and creatively satisfying work. As designers, we live to solve problems, and few problems are larger than those lurking in the inner depths of a global organization. After all, Fortune 500s tend to have a “just get it done” attitude toward internal tools, resulting in user experiences that aren’t well designed or tested. By giving those tools the same attention to experience that you give consumer-facing products, you can improve the lives of your users and support the organization’s values and brand.Why bother with enterprise work?
Enterprise UX is often about solving ancillary problems by creating tools that facilitate an organization’s primary goals. These problems are rarely as compelling or visible as the goals they support, but they’re just as necessary to solve. A company might build the best-designed cars in the world, but it won’t matter if its quality-assurance process is hobbled by unusable software. Good design enables enterprises to do the work they were founded to do.
Enterprise employees are also consumers, and they’ve come to expect consumer-level design in all the tools they use. Why shouldn’t a company’s inventory software or HR portal be as polished as Evernote, Pinterest, or Instagram? When a consumer app is poorly designed, the user can delete it. When an enterprise app is poorly designed, its users are stuck with it.
The stakes can be enormously high. The sheer scale of enterprise clients magnifies the effects of good and bad design alike. Small inefficiencies in large organizations result in extra costs that are passed on to the end user in time spent, money lost, and frustration increased. Likewise, when an enterprise prioritizes user experience for its internal tools, it becomes a more effective organization; a recently released business index shows that design-driven companies outperformed the S&P average by 228% over the last ten years.
A perfect example of the business value of enterprise UX is found in the article, “Calculating ROI on UX & Usability Projects”:…if you optimize the UX on a series of screens so that what was once a 5 minute task is now a 2.5 minute task, then you’ve increased a person’s productivity by 100%. That’s huge. HUGE. If the company has 100 phone agents who have an average salary of $40,000 + benefits (~$8,000) (+ an unknown amount for overhead), you could either release or retask those agents on other activities with a savings of $2,400,000/year. (half of 100 agents x $48,000).
It’s simplified, but the point is dead-on. A company with 100 phone agents could result in millions of dollars of savings. Imagine the impact on a company with thousands of employees? Or tens of thousands?
We have an opportunity to set the tone in some of the largest industries on the planet. Many big organizations have been defined by engineering and business thinking, with any design being either incidental or unintentional. Now, as those companies wake up to the value of solid design, they have to contend with the years of cruft that have obscured their tools and processes. Design is essential to shedding the excess and building better, leaner, and more human organizations.Working on enterprise projects
There’s no such thing as an average enterprise UX project. The variety of projects within even a single company can be dizzying. I’ve worked on sites with a million visitors in the first week, and apps that fewer than 12 people use in a year.
Projects that would be iterative in the consumer space may be a one-off in the enterprise space, so it’s crucial to get things right the first time around. Further, due to cost, culture, and the immense hassle of rolling out updates to tens of thousands of employees, enterprise clients are often bogged down with wildly out-of-date solutions. We’ve heard of huge companies begging Microsoft to extend the lifespan of Windows XP; that’s the rule, not the exception.
Designing internal tools for a Fortune 500 company requires adaptation, but it isn’t a seismic shift from the world of consumer-facing design. Though a set of universal rules governing enterprise UX might not exist, there are a few principles I wish I’d known when transitioning from working with smaller clients.Design for the end user, not the client
As with many design jobs, the end users of your software probably aren’t the same people who commissioned it.
In large organizations, the divide between the user and the client can be vast. The director of operations might commission an inventory app for warehouse personnel, or someone from IT might commission a reporting tool for the sales team. In an enterprise-scale bureaucracy, the clients in charge of UX projects are often in higher-level management roles. And while they typically have an invaluable grasp of the big picture, they may not completely realize the everyday needs of the people who will use the software.
Conduct your stakeholder interviews to understand and agree on your client’s business goals, but don’t forget to gather user and empirical data too. Fortunately, that type of research is easier to do in an enterprise setting than in the consumer space. Corporations like to quantify things, so data on productivity and software use may already exist. And, unlike consumers who need an incentive to fill out a survey or participate in an usability study, enterprise users have an inherent investment in the end product—setting aside some time to answer your questions is part of their job.
A successful enterprise UX project considers the users’ needs, the clients’ goals, and the organization’s priorities. The best user experience sits at the intersection of these concerns.Be an educator and advocate, but above all, be flexible
Being a designer is as much a consultative role as a practical one; to justify our design decisions, we need to explain to clients our guiding principles and teach them the basics of good user experience. Otherwise, we’re nothing more than pixel-pushers.
Most enterprise clients have their own procurement procedures and project management techniques that don’t jive with a healthy UX workflow. Designers often find themselves needing to shoehorn their process into an existing structure, an exercise which can be frustrating if not approached properly.
I was recently involved in redesigning a section of a large corporation’s website. My team was responsible for handling the visual design—the content was set, and a development partner had already been hired.
Ordinarily, we prefer to have plenty of overlap between the design and development phases, to ensure that the live site matches the intentions of the design. However, the tight deadline and the client’s existing workflow made this impossible. Instead, we handed off the final mock-ups to the developers and hoped that everything was implemented without a hitch.
We didn’t see the site again until a week before launch. Predictably, the soon-to-be-live site had numerous inconsistencies. Issues that would have been obvious with a glance from a designer—incorrect fonts, uneven margins, wrong colors—were left until the last minute to fix. The process provided ample room for the developers to do quality control (remember that ancient tech stack?), but not the designers.
We wrote a list of crucial changes, ordered by priority, to bring the site in line with our design and the client’s goals. Many items were fixed before launch, and the client fast-tracked a second iteration to fix the rest. But none of those design issues would have launched in the first place had we insisted on more interaction between the designers and developers. Some good did come out of this challenge: we recommended the client reevaluate their design/development workflow requirements, explaining why the two processes needed to overlap. We also examined our own workflow to figure out how to make it more accommodating to the peculiarities of enterprise work—adding a postmortem phase, for instance, enables us to give feedback to a third-party developer while maintaining a tight timeline. If we were asking our clients to be flexible, we needed to be flexible too. Sure enough, the client offered us a greater opportunity to set the terms of the process on the next project.
Needing to adapt to a new set of restrictions is an opportunity, not a hindrance. One of the most valuable things a designer can offer a large organization is insight into the design process and its importance. Design education and advocacy can extend beyond a single project, giving the client an understanding of how to better accommodate design thinking within the organization.Learn the culture, speak the language
Designing internal tools for an organization requires an understanding of that organization’s culture, from the basic mindset to the quirks that make it unique.
Corporate clients are often forced into short-term thinking, which can make it difficult to push longer-term design goals. When dealing with enterprise clients, remember their priorities: meeting a quota by the end of the quarter, exhausting a budget so they can secure the same amount next year, or improving a metric to keep the boss happy. Corporate clients are less concerned with design trends or UX best practices—they just want something that works for them. It’s best to frame design decisions around the client’s goals to sell them on your thinking.
Of course, that’s easier said than done. It isn’t always obvious what the client cares about. Plenty of organizations pay lip service to values that haven’t really permeated the culture, making it hard to know what to aim for in the design process. It’s amazing how many enterprises describe themselves as “design-focused” or “innovation-driven” without anyone below the C-suite knowing what those terms mean.
So how do we figure out what an enterprise client is really about?
It takes some time, but one of the best ways is to pay attention to the language your clients use. Different organizations have different vocabularies, which reveal the way they think. You’ll likely encounter jargon, but your job is to listen—and help your clients translate that language into actionable goals. Do employees talk about “circling back” or “talking about this offline”? Structured communication may be important to that company. How about “value-add” or “low-hanging fruit”? Quick wins and return-on-investment are probably cornerstones of that organization’s culture.
No client wants to learn design lingo just to be able to communicate with you, and corporate clients in particular are busy with a million other things. Learn their language so they don’t have to learn yours.Go ahead
We designers live to solve problems, and enterprise organizations provide fertile ground. They present a different set of constraints than startups and smaller clients, and while some designers balk at the idea of their work being constricted by a bureaucracy, others remember that the best design flourishes within well-defined boundaries.
Working on enterprise projects is something every UX designer should try. Who knows? You may just like it enough to stay.
I’ve spent most of my career at institutions of higher education, and during that time, I have had the good fortune to work with several incredible students. Former interns are now LinkedIn connections working for television shows, book publishers, major websites, ad agencies, and PR firms, and the list of job titles and employers makes me proud. Along the way, I tried to give them interesting projects (when available), enthusiastic references (when merited), and helpful career advice (when requested).
And despite their success, I feel like I fell short. I could have offered more to them.
Mentoring opportunities, after all, aren’t limited to internships and official programs. There is a lot that we as individuals can do to serve as role models, ambassadors, and teachers to the web professionals of tomorrow.
Skillsets will evolve and technologies will come and go, but we can create the digital experiences of the future today through the values and attitudes we instill in the next generation of web workers.Finding new layers of learning
The web has matured significantly since it hijacked my career path back in college, and so have our understanding of and attitudes toward it. “Doing it right” calls for strategic skills like testing, measurement, and planning; interpersonal skills like negotiation, leadership, and collaboration; and technical skills in writing, coding, or design.
But has the education of the next generation of web professionals matured accordingly? How much are they learning bricklaying versus architecture? This isn’t meant to be a condemnation of curriculums at colleges and universities, where we are beginning to see more courses, certificates, and even degree programs that reflect this approach. This is more an acknowledgement of the new nature of education nowadays—experiential, fluid, occasionally roundabout, and highly networked.
We often talk about how the success of our work is determined by the strength of our relationships and our ability to work with people. This is what Jonathan Kahn has been talking about and working on with the Dare Conference. We need to extend that way of thinking to the relationships we build with each other, and, in particular, with the future professionals who will one day take our place at the client’s table.
I’ve always cherished the thoughtfulness that our industry regularly displays, and how, despite serious concerns about sexism, diversity, and harassment, there is an overriding sense of justice and support. Within our profession, we have built a special community. Since our future colleagues are among these students, let’s welcome them into it.Bring your experience back to the classroom
Future web professionals require connections to peers and leaders in the field and to enhanced learning experiences. We can build those connections by meeting students where they are: in their classrooms. What undergraduate or graduate programs offered in your area align with your skillset? Reach out to the relevant faculty—in journalism, public relations, computer science, human-computer interaction, graphic design, technical writing, and other departments—to see if they are looking for guest speakers.
Brand and content strategist Margot Bloomstein has spoken to undergraduate classes about a half-dozen times, and invited top names in the field to speak to her own content strategy class at Columbia University. My Meet Content partner-in-crime, Rick Allen, teaches a course at Emerson College in Boston on electronic publishing, and he’s been kind enough to invite me to speak to his graduate students twice (and sometimes I think the experience is more rewarding for me than for them!).
You can also reach out directly to college career centers. Amanda Costello, a content strategist at the University of Minnesota, has had success with this approach, working with them to organize and promote events where she can talk about her work with students who may have an interest in a web profession.
If you catch the bug after a guest-lecturing stint, reach out to those programs or your local community college to see if they are looking for new adjunct faculty, and teach your own course. It’s a huge time commitment, to be sure, but teaching is a great way to approach your work with fresh eyes and maybe realize a thing or two you didn’t know before—while sharing your knowledge with an eager audience.Expand learning opportunities off-campus
Invite students to the next local industry event. Hackathon? Content strategy meetup? UX book club? It’s all good. Work with professors teaching relevant courses to see if their students can get extra credit for attending, or maybe host a “student night” of lightning talks where they can talk about their research or perspectives on the field so far. Similar to Costello’s approach, send information about your professional networking event directly to career centers so they can promote it to students who may be interested.
We can also make powerful connections outside the construct of a university setting. Karen McGrane recently wrote about how she pays forward the 30 minutes an academic whose name she can’t even recall gave her that helped steer her toward a graduate program and, eventually, a career.
With that post echoing in my mind, I recently agreed to meet with a young woman who reached out to me via Twitter. She was intrigued by my job title, curious about how I got to where I am, and wondering what her next steps might be. We closed our 30-minute conversation over coffee on an Au Bon Pain patio with me promising to connect her to a former intern of mine, whom I had counseled as she struggled to find her place postgraduation and watched as she emerged confident with a rewarding job in her chosen field.
I don’t know if that connection will help her, or if anything I said in those 30 minutes made sense, but if nothing else, I know that I helped reassure her that there are people in the industry who are willing to meet a complete stranger for 30 minutes on a Tuesday and talk shop. For someone just starting out professionally and looking to find her place, that’s significant.Make conferences more accessible for young attendees
We are lucky to work in an industry with several opportunities for professional development, events where we can gather in person and learn from each other. We need to work harder to bring college students into this fold. There are two main obstacles: awareness and budget.
Building the pathways to make students aware of conference opportunities (both for presenting and attending) is doable over time, but a tougher problem to solve is budget. The average college junior does not have the resources to pay a conference fee, let alone airfare and hotel. Within a university, a student may receive funding from the provost’s office or a dean’s special-projects fund to attend an academic conference. But what about professional events?
As sponsorship dollars fly fast and furious around various events, let’s consider the possibility of offering scholarships to select student attendees or a discounted student rate, as some conferences (like An Event Apart) already do. In this vein, for two years running, Facebook has sponsored content strategy fellowships that fund three students’ attendance at the annual Confab Central content strategy conference, in addition to extending an opportunity to apply for a content strategy internship with the social-networking giant. Some conferences, like UXPA, organize a student volunteer program that helps staff the conference while providing a free conference experience (complete with networking opportunities) in return. If sponsorships and scholarships aren’t possible, conferences should work with colleges to allow attendance at events relevant to a student’s major to count as course credit.
But what about taking that a step further and creating a professional development experience just for students? Two such initiatives are currently underway. One is the Center Centre at the Unicorn Institute, a user experience design-focused education project spearheaded by Jared Spool and Leslie Jensen-Inman. Also, the HighEdWeb conference has introduced the CrowdSource Summit, a sub-conference geared toward college students with the stated goal of providing them with a multidisciplinary, human perspective on web professions. (Full disclosure: I spoke at CrowdSource Summit in October.)
While attendance is great, presenting is even better. In helping to organize Confab Higher Ed for the past two years, I am particularly proud of the fact that we have included sessions that feature not only student-generated communications efforts, but also teams with student copresenters. And offering those opportunities can yield results. Recently, I learned that one of last year’s student speakers, RIT’s Erin Supinka, landed a job as a social media manager at Dartmouth in part thanks to the recommendation of Dartmouth content strategist Sarah Maxell Crosby, who attended Supinka’s session. I hope to see this trend continue, and be echoed at other conferences.
This increased access for students would have to go hand in hand with making conferences’ social activities less focused around drinking and creating more all-ages social events. A List Apart technical editor and front-end developer Anna Debenham recently wrote about this on the ALA blog, observing that all of the efforts I’ve outlined here would be for naught if we don’t address the social component as well. “The more young people we encourage to join the fold, the more we are excluding from these events,” she observed. (Debenham has even crafted some handy guidelines for event organizers.)Expand your interns’ horizons
If you have interns at your company, don’t limit their involvement to tasks like research, answering emails, or bug fixes. Get them invested in the culture of your organization by discussing clients, projects, process, deliverables, and industry trends and challenges with them. Let them sit in on a kickoff meeting, client pitch, or deliverables presentation, and encourage them to share their ideas in whatever way is most appropriate. Earlier this year, Jim Ross wrote for UX Matters not only about how interns can get the most out of their opportunity, but also how companies can give interns enlightening, productive work experiences. The Boston-based web design firm Upstatement offers a development apprenticeship that seems like it would be one such position.
The other day, I sat in on a weekly status call with a client. Our project manager called in our co-op student who had worked on a landing page design and asked her to explain to the client the different options and the reasoning behind them. The PM could have easily summarized the work, but instead she asked our co-op to represent her own work—which, I might add, the client liked.
In addition, have interns talk to people in roles that are distinct from their skillset or comfort zone—programmers, project managers, IAs, UX specialists, content strategists, designers, you name it. These mini job-shadowing opportunities will help establish a well-rounded approach to web work.
A couple of years ago, I wrote for Meet Content about how student workers can help support content strategy work (both from the staff perspective as the one managing the students and assigning them work, and from the student perspective of someone thinking about a career path and looking for paid work that will help advance them along). Last year, a design intern at Fastspot wrote glowingly on the company’s blog about how deeply involved she became in the agency’s process while working there. It’s within these purposeful, immersive early work experiences that students discover their true callings as professionals—as well as the things they don’t like, which is important too.Building the future
In a 2010 HighEdWeb presentation, Dylan Wilbanks (then at the University of Washington) exhorted the audience not to let the politics of higher ed beat them down and make them bitter. “Love the web, love higher ed, love people,” he implored us.
In thinking about the importance of mentorship, I am drawn back to Wilbanks’s words. We may love the work that we do, yes, but we also love our field and the people within it. This love is why I care about what not only the web will look like in five, 10, 20 years, but also our profession and our community.
In an August post on The Pastry Box Project, Brad Frost reminded us of the importance in remaining self-aware as professionals, always asking ourselves why we do what we do and not just getting dragged along by the act of doing. “Understanding why we enjoy doing what we do better prepares us for whatever the future has in store,” he wrote. In short, we need to actively give a damn.
The more we openly communicate about what drives us, the better off we, our colleagues, and our future colleagues will be. We use forums like this to debate and evolve our understanding both of the web and of ourselves as professionals, to everyone’s benefit.
By the same token, because we care so damned much, we should be similarly engaged with the next wave of web professionals. We should work to cultivate their senses of passion and exploration, and their appreciation of a well-rounded approach to web work, so they can take the web places we’ve never dreamed it could go. Now that’s being future friendly.
Zoe woke up at some point in the night. I have a vague recollection of a conversation with her, and lacking the willpower to get out of bed to put her back to bed in her own bed. The next thing it was 5:30am and she was sleeping sideways in bed with me.
Despite all that, I felt more rested this morning, which was good. We managed to get going quite early as well, without really trying. I had to be out at the Sleeman Sports Complex at 9am for a roadshow by the REIQ about the new Property Occupations Act, which kicks in on December 1 to replace the current Property Agents and Motor Dealers Act.
It also rained this morning, which doubly made it necessary to go to Kindergarten by car. We were actually running so early that we got there before opening time, which I've only managed to do a few times all year.
I ended up getting to the Sleeman Sports Complex about 15 minutes early. It was fun playing "spot the real estate agent's car".
I didn't learn anything earthshattering in the briefing, but it was useful to get fully up to speed on the new legislation. I just hope that being half way through a course that has covered the old legislation isn't going to be a problem.
I got home from that with enough time to just chill out for a bit (I ended up doing a bit of tinkering) before it was time to pick up Zoe. The weather was still a bit questionable, so I picked her up in the car.
Zoe wanted to watch Megan's tennis lesson again, and I had to be at home for a 3pm video chat, so I left her with Jason and popped home.
After my video chat, I went around to Jason's and helped with a bit of painting before heading home to start on dinner.
I had enough for Jason, Megan and Megan's little sister, so they came over for dinner as well.
I got Zoe down to bed at the normal time, but her bedroom is ridiculously hot. I'm not terribly confident I won't get another uninterrupted night's sleep.