I've been a senior computer scientist for the government of Canada since 2018. There's a lot of hard truths public servants are never told because reality doesn't reflect the official messaging, or nobody wants to take the risk of stating it. So this page lists some of my own guidelines, truths, and tools that have most helped navigate my career in government and guard my sanity. I hope this page is especially useful to anyone new in government, especially tech people who care about doing a good job.

Caveat: Government is huge and teams are different. I hope this generalizes well and I think it does, but my personal experiences are clear biases.

Starting with the most important items:

Why Not What

Understand the "why" of a rule not the "what".

If you understand why a rule exists and you do not violate that then you can sometimes not follow the literal details of the rule and it's fine.

For example ask yourself "why" is this the deadline or "why" is there a deadline at all? Maybe someone made a promise to management and not being ready will be embarassing. The "why" of the deadline may actually just be for that person to feel okay. Respect that "why". The literal specific deadline is less important.

In government people only really care if you violate the spirit of an important rule, not its details. Be honest, thorough, and upfront about following the spirit of the rules and you can bend deadlines, simplify processes permanently, and skip "requirements".

See also Chesterton's Fence.

Social Media & Political Activities

Nobody cares unless your views are fringe or you're a manager+.

Officially public servants can have virtually no voice on social media, especially for political statements critical of the government. However in reality this only starts to matter based on these factors:

• are your views fringe or extreme?
• are you a manager+?
• are you using your real name?
• are you prominently declaring that these are public servant political opinions?
• are you big or loud enough to be picked up by legacy news media?

I've been told a few times by the Values & Ethics (V&E) team that I cannot identify myself as a public servant on social media. I've replied that most of my colleagues, my manager, my director, DGs, and DM are all active on LinkedIn so I'm refusing to do what they say.

It's not the job of the V&E team to give reasonable practical advice to help public servants live their lives. Instead they interpret rules with extreme caution to protect the employer. They are only advisers and only your supervisor can tell you what to do.

GTD

All serious professionals have some kind of organization system.

There's a personal organization system called Getting Things Done that I've modified and used for many years. I won't go deep in this section about GTD but if you don't have any organization system you absolutely need one if you want to be a serious and trusted tech professional.

Some core concepts of GTD include:

• Don't clutter your brain tracking what needs to be done next.
• Keep checklists for weekly, monthly, tri-monthly, and yearly reviews.
• Reviews should not take long. You're not executing tasks during reviews. Instead you're getting organized and prioritizing.
• Define the very next tiny task to make progress for your short list of ongoing projects.

And more. I also maintain and execute checklists for events like "new member of the team".

Deploy First, Justify Later

"You can't justify a bridge by the number of people swimming across a river."

Sometimes, the people who will benefit from a new project most may never understand the benefits until the benefits become real to them.

Several times now, I've recognized that it would take more time and effort to justify a project than simply deploying a proof of concept that people can try out for real. As a professional some of your work hours are appropriately assigned to developing your own ideas that you judge to be useful to your team. Take time to do what you think is best. Use the results to justify the project later.

Bizarro World Training

Most government training is not worth doing thoroughly.

I recommend you don't waste your time on any government training unless it's something also available to people outside government. For example PIPSC members (IT) have access to some training platforms that do courses and certificates private citizens might pay for. Courses from accredited universities can also be a good idea.

There's this whole bizarro world of government training which is totally insulated from reality. It just gives people something to do or checks a box. See also "Training Spreadsheet".

A hospital administator cannot order a nurse to lower their standards and harm a patient. Similarly, all professionals have a responsibility to spend their time wisely and not blindly do as they're told. Spend your valuable time only doing the best training available to you. Skip or do the minimum to pass all other types of training. Ask yourself "why does this mandatory training exist?" and if that's not for your professional development then spending an extra hour doing it thoroughly is a bad decision and nobody will care that you did.

Training Spreadsheet

Nobody is tracking your training history. Track it yourself to skip duplicate mandatory training.

There are many training divisions, departments, platforms, vendors, and accounts in government. It's a huge mess and even on just a single platform nobody is responsibly curating your training history data as the years roll by.

I have a spreadsheet on my personal cloud drive called "Stuart Spence Training History" shared read-only with anyone who has the link. Currently it lists 79 government training courses I've completed with columns for name, code, completion date, and links to certificate files if any.

In government you will sometimes get random emails for some "mandatory training course". The content is generic and forgettable because the "why" for this training is not any measured training outcome (see "Bizarro World Training"). Did you already do this course? Or was it just named similarly? Where was that certificate again?

Several times I've replied to these emails like this:

I see this course is called "Navigating Ethical Turtle Acquisition in Government". Well three years ago I completed "Turtle Acquisition Values & Ethics" however it had no course code. Here's the certificate. Have I already completed this course?

Often the answer is yes. I saved myself an hour or two and I can tell my supervisor I've met the requirements.

Monthly Summaries

Everyone feels like you did nothing this month until you write it down.

Most work days, I write a few words into a private spreadsheet describing what I did. Each row is a day.

Every month, I write those notes into a monthly summary. I review a checklist of things to help me remember my month like my spreadsheet, project contributions, and my calendar. The summary is short and doesn't take long to write.

Every month I share this with my supervisors. So it doesn't matter how busy or distracted a supervisor was - every month if they spend 30 seconds they get a pretty good idea of what I've been doing. This also makes it easy for them to write the PSPM yearly reviews. See also "Help Your Supervisor".

If you can access gcpedia, you can see my summary for every month since 2018. However the basic format is:

# January 2026

Here's what I did this month, starting with most time spent. 

* Category/Project: (1-3 sentences with links)
* Category/Project: (1-3 sentences with links)
* Category/Project: (1-3 sentences with links)
...

This is your career and your data. Make sure it can be widely shared (gcpedia) and that you have a personal backup.

Assume No Action

Suppose you're ignored forever. What will you do about it and when?

Suppose you send an email or submit a ticket and now you're waiting on someone else. Maybe you have no working relationship with them yet and don't know how much you can trust them to followup. Maybe you know they won't followup. Maybe the ticket platform has a history of closing your tickets with no notifications.

Ask yourself: let's assume they never address this. By what date do I need to take some action, and what is that action?

Set a reminder to yourself to do that on that date. Now you should clear your mind of this and work on anything else.

See also "GTD".

Declare Your Own Approval

Put it in writing that if you hear nothing by some date, you assume you have their approval.

Suppose you need some kind of approval (like security, ethics, legal, AI assessment) from some team however they have few resources, or your project requires new kinds of processes or evaluations. You've been waiting for weeks or months, you've escalated, and this otherwise simple evaluation is going nowhere. Maybe you're even starting to get ghosted.

Next step: Write out the new process. Evaluate yourself. Write a nice PDF with a title, executive summary, author, date, and even pretty colors. Share it with the team with a note like "Here's a new draft process I propose and how I evaluated my project." Provide a date deadline for them to provide feedback, and write that you're assuming they're okay with all this if you get no response by that date. You get no response. Now you can move forward.

Yes, you're doing their job. Yes, you shouldn't have to. No, this isn't exactly an approval. But remember the "Serenity Prayer". Do what's best for you and your projects.

Be sure to CC many people.

Related quotation:

Seek forgiveness, not permission.

Identify Their Goals

If you think someone is incompetent or lazy, maybe they just don't share your goals.

I want to build software that's useful, simple, maintainable, robust, and automated. I also want to teach and help with training. I'm pretty transparent about all this and I hope that transparency helps people understand me and work with me.

Not everyone shares these goals. Here are some examples based on real experiences:

• Directors are pushing hard to sign a huge contract with expiring cloud credits when we don't even have the staff to use what we have now. Superficially this may seem incompetent. But their goal may be to sign the largest dollar amount contract that they can to advance their careers. So arguing that it's too expensive is a bad argument because they like that it's expensive. Argue instead that it will be embarassing when we waste all that money.
• Developers are over-engineering our software by adding frameworks, databases, components, and cloud vendors for what could have been simple software. You might think they're inexperienced and don't know how to build simple things. But their goal may be to try out new and modern tools even if it makes no practical sense for the project - maybe for fun, maybe for Resume Driven Development (RDD). So arguing that a component is overkill is a bad argument because they want to explore that overkill. Argue instead that it's bad for your career to bloat a project until it dies. Delivering good software to production that's still used today is the best thing to put on a resume.
• Support teams are apparently refusing to provide automation and instead insist on tickets and manual solutions. You might think they don't understand the merits of automation. But their goal may be to just clock in, click around to close some tickets, and clock out. So arguing that we can all work hard together to automate is a bad argument because they don't want to. Consider accepting that their "support" is not real and you need to find other contributors or do it yourself.
• Non-technical people are scheduling too many pointless meetings that could have been an email. You may think they just need to learn about manager schedule and maker schedule or we can design a working agreement with fewer live meetings and more asynchronous ticketing. But their goal may actually be to attend meetings, burn through their day, and clock out. A cancelled meeting may be an empty block of time where they need to find something to do. If you find a good solution to this one, let me know.

Process Not People

Attack the problem - not the person.

Identify bad processes - don't blame people for being stuck using bad processes. Offer to help people with their work - don't blame them for not having the resources to help.

You blame someone today and someone else will blame you tomorrow. You'll be stuck in a toxic mess.

Conway's Law

There are many laws, theories, principles and patterns for developers and I recommend becoming eventually familiar with most of them. One of the most relevant to government is Conway's Law:

Software architecture mirrors the org chart.

Government of Canada silos are strong. It's an important skill to recognize when immense software complexity was not designed intelligently with purpose. It's just a result of Conway's Law. If you want to improve this kind of software, you also need to think about the org chart and include non-technical strategies like building human connections with teams.

Serenity Prayer

"Grant me the serenity to accept the things I cannot change, the courage to change the things I can, and the wisdom to know the difference."

Example: The employer provided headset hurts your ears and has bad audio quality.

The mandated headset choices are terrible but you (likely) have no power to fix that problem and need to accept that. Have the wisdom to buy your own excellent headset with your own funds. Yes it's not technically a thing you must do. But you use this equipment everyday and your life will be much better. Have the courage to announce this in conversations: "the employer doesn't provide me with the equipment to do my job".

Maybe your courage does have the power to fix this some day. But today, you have a great headset.

Help Your Supervisor

Help your supervisor. Not the other way around.

One of your top priorities is not being a burden on your supervisor.

• Ask them what is hardest about their role and how you can help. You'll learn what's most important and may be given higher level work.
• Write summaries (see "Monthly Summaries") so they don't need to work to understand what you're doing.
• Thinking up solutions to problems is work. If you can, do that work so they don't have to. They only need to choose.

It's natural that you're a time sink for your supervisor when you start a new role. But try to be useful and save them time as soon as you can.

Say No

It's an extremely important skill in life not to do things for people just because they told you to.

For the past few years I've let my supervisors know that I like to spend 10% of my time teaching or making training materials. This has always been well received. Sometimes this puts me in contact with training teams who like what I've made. Sometimes training managers want to steer my enthusiasm and efforts into their own projects which are stalled. Or sometimes they're pretty assertive about how I should change my format or style or follow their standards. They're not my boss. Just because they ordered me to do it doesn't mean I have to.

Plant Seeds

Plant many seeds. Do not get too attached to one project.

In government sometimes excellent and no-brainer projects get held up for months or indefinitely. Or, a project that should take a week can take a year because of all the slow back and forth. Or a project is 95% done, is proven useful, and then cancelled.

Roadblocks that destroy or cancel your hard work can be upsetting. So hedge your bets and have many things on the go. In the past, a supervisor was concerned that I was spending too much time on one of these seeds. I just let them know that I've spent about 1 hour per month for 2 years on it. They only thought I was putting a lot into it because they kept hearing about it as I made slow steady progress. I also didn't lose track of it because of my organization system (see "GTD").

Most of these seeds die. Government makes it especially hard to predict which will thrive. That's okay. Some seeds grow into surprising successes and save your sanity.

Design Goals

What are the conditions to stop this experiment?

In government people are a bit loose with the terms prototype, experiment, and proof of concept (PoC).

Often the purpose of these is to answer a design question. For example:

• what would this web tool look like?
• what would using this web tool feel like?
• will this technical approach run in under a minute?
• about how much will this cloud solution cost?

Every PoC should have clear design questions. Answer them as quickly and cheaply as you can and then shut down the experiment.

If you can't shut down an experiment because people need it, then your PoC has mutated into a service. Maybe nobody wants to admit it. Start treating it like a service and stop calling it a PoC.

Closing Thoughts

I hope this was useful. Do you think anything could be added to this page? Let me know.

Best of luck!