Cloud Management

TODO: Get job as Dev

This is an article for those of you who are self-taught or coming out of an accelerator/bootcamp program for software development, who are wondering what’s left to do before you land that first software development job.

This is based on my experience of hiring people in this situation for several companies.

First things first; yep, you’re at a slight disadvantage vs. “classically trained” software developers or engineers from University programs.

No, that disadvantage is not insurmountable. If you combine your dev education with other attributes (like your great non-software experience), and apply it in the right role selection, you’re golden. It’s a great time to be getting into software.

Full-Stack Roles

Unlike the specialized roles that sometimes require Master’s level education in specific areas, full-stack roles are constantly available.

The reason being: small software teams need excited generalists, who can demonstrate competency throughout the tech spectrum (from updating WordPress websites to building out new infrastructure in the cloud).

You’ll find many unfilled full-stack roles in the IT / tech organizations of non-technology organizations (ex. mortgage providers, agrifood manufactures, automotive parts suppliers).

Google, Facebook, Amazon, Shopify, Square etc. are key destinations for excellent talent, and pay appropriately. Non-SaaS organizations that are doing meaningful technology work struggle in that hiring landscape and are willing to hire from bootcamp programs and develop non-degree talent in house.


Front-end refers to the part of the software that users can interact with. While it includes mobile apps and web sites, it also includes documentation, email, and social systems that accompany software solutions.

From a new-grad, employers expect:

  • Demonstrable skills in one or two modern UI technologies. In 2022 that means React + Redux, Swift, Dart/Flutter, Kotlin, etc.
    • Focusing on JavaScript + HTML + CSS + jQuery + PHP is considered an anti-pattern, despite the fact that’s required for developing and improving older websites. Not great, agreed!
  • Object-oriented design principles and design patterns: Factories, Singletons, Decorators, Observers are common-place.
    • Understanding views, models, controllers, and related patterns (MVVM and MVC).
  • Concern for user experience and design. You should have an opinion if the interface is mixing serif and non-serif fonts, image alignment is inconsistent, or the affordance of a key action is low.
  • Constructive relationships with people testing, critiquing, or evaluating your work. Testers, QA, managers, stakeholders, and clients need to have positive, creative relationships with you.
  • Examples of accurate, and well-edited technical written communication.
    • Hate to say it, but knowing how to administer a WordPress instance is a friendly docs bonus.


Most students of software start their journey on writing back-end code. Back end code is rewarding to author, testable, structured, and ripe with technology options. It’s the good stuff other devs like to look at and discuss.

Though unless your job specifically concerns DX, it tends to be far from the value your team creates. So the key skill is knowing enough to know what’s fit for purpose.

New grads are assumed to have:

  • Working knowledge of RESTful API design and protocols of the web request/response pattern (ex. Content-Type, CORS, headers, cookies) .. as REST and HTTP are the protocols of choice for modern tech.
  • Though, the future of APIs is event-driven. Academic understanding of events, buses, cloud functions is helpful.
  • Comprehensive understanding of relational databases; how to query with SQL, table design, relationships between models.
    • The technology of the DB rarely matters (Postgres, Microsoft, Oracle, MySQL, etc.) as the principles are universal.
  • Understanding how documentation stores (ex. NoSQL) and key-value caches (ex. Redis) differ from relational databases, and when to use which, is important when developing new features or products.
  • Performance monitoring and profiling in general, using tools like Firebase, Crashlytics, Microsoft Insights, Papertrail, etc. is key for keeping back-end services up and running. Practical experience in keeping your work up and running under load is great.


While often part of the “back-end”, infra is becoming a field on its own, as it can be represented as code and configuration.

This is where self-taught and bootcamp developers often have an advantage over University programs — few degree programs have infra in the curriculum.

Employers love to see:

  • Experience with a few “clouds”: Azure, AWS, or Google Cloud being the most important.
  • Understanding of the role Docker + containerization play in software deployment. Kubernetes configuration is a next-level skill, and likely not worth the attention it gets in the computing community.
  • Experience working in a work management tool (Jira, Azure DevOps, Trello etc.) with a pipeline that does integration and deployment.
  • Once again, cloud functions and storage buckets are more often the right ways to build back-end services.


Sometimes people feel that their experience in Bootcamp was great, but not enough to land them software development work. A couple of practical next-steps:

  • If you have a Bachelor’s degree in another field, and a bootcamp credential, you may qualify for a post-grad program in software development at your community college. These programs are often awesome: an intense year of programming up-skilling, sometimes coupled with a co-op program. In Kitchener-Waterloo, Conestoga College offers a program like this that I’ve hired out of several times.
  • There are many Business Analyst roles at technology companies that require expert understanding of a field, coupled with project management and technical software skills. BA roles often have career paths into QA and Solutions Engineering, and they are sometimes attached to a software team. The role may seem junior, but it puts you at the intersection of valuable business work and technology. BA also has career paths into management, sales, and other orgs. It’s a very flexible role in technology companies.
  • Software companies need application support, and support engineers who learn the deep technical aspects how software works for clients. Application Support Engineer is a fast growing field, replacing the old “customer support” + “Tier 3 developer” model into a shared role. The role generally has a well-defined career path into software development for those who stand out.

Hope you find this helpful, and good luck getting into the field!


Building Inclusive Teams

Making a team inclusive is not some HR challenge, but within the mandate of any people manager.  As a manager, how do you set up an inclusive team?

(Most of these hot tips are things that I’ve seen work at great Canadian organizations: D2L, Tulip).  All credit for the correct stuff goes to them.


  • Compensate people equitably and pro-actively; nothing fair can progress without that.
  • When team-building, stick to activities relevant to the teams function.
  • Be explicitly respectful of personal, cultural things
  • Focus on your people’s needs
  • Be patient with hiring to adhere to your team values.


Money is the great equalizer.  Start with your own, personal compensation review of all salaries, benefits, and bonuses paid out to your team.

If the compensation on your team isn’t equitable based on annual performance and role responsibilities, inequity and privilege are there on the ground floor of your employee-employer relationship.  These base forces are almost impossible to overcome.

Regularly review salaries + job descriptions, and make adjustments to keep things equitable.  Every 2 quarters is a realistic cadence.

Or better yet, work towards a predictable salary grid (avoiding the pitfalls of negotiating at level changes).

Hire Slowly

When hiring quickly we generally bias towards the most available, most accessible, qualified candidates. We favour the person that we connect with, or evaluate them based on personal criteria to satisfy who we need now.

Give yourself the time to assess candidates.  I know this is hard in the modern employee market, but at least take the time to identify things that truly matter to your team long term: attitude, core skills, value fit, growth goals.  Try stuff like removing names from resumes, and screening resumes independently (to avoid that initial group-think)

Let the team do most of the hiring. As the manager, be part of the process identifying bias and assumptions, and helping push the process along positively. 

Vice Squad

In the 2000’s / age of kegs at the office, some people never felt comfortable drinking or being around alcohol. 

Here’s a short list of reasons people don’t want to drink at work functions:

  • pregnant (or trying)
  • picking their kids up from daycare
  • on strong meds
  • religiously abstaining
  • wife asked to cut back

This is personal stuff that has nothing to do with the teams work;  don’t exclude people from team activities because of it This extends to other inebriates and vices as well.  ex. cannabis, gambling.

If you want to build an inclusive team, don’t team-build around exclusive activities. Wine at dinner? Great.  Meeting at a bar. Not good.

Making friends isn’t the same thing as team building.  No doubt, shared vices and debauchery make better friends; but building an inclusive team is a different activity.

Religious / Cultural Accommodation

A simple way to ruin team cohesion is to make people feel uncomfortable about their religion or lack thereof.  Theism / atheism / religion is personal and cultural, and shouldn’t really influence your work team identity.

Appropriately accommodating is not always obvious.  If something comes up, park it, and respectfully bring it up in a one-on-one as it relates to your activity  (“Anything we should avoid for weekly lunch? Need any additional time away for family holidays?”). Trying to deal with things on-the-fly tends to be embarrassing for someone.

Small example — I’ve started making Diwali a team holiday, due to the number of Hindu people on our teams and vendor networks, rather than awarding it to people who ask.

Small example — I’ve stopped asking people where they are traveling to.  Sometimes it’s a pilgrimage, or a cultural rite, and they don’t need that to be a thing at work.

What about Christmas?!  I embrace the inclusive levity and kitsch of it.  I celebrate Christmas at home Euro-traditionally, but at work an over-the-top Christmas tree with a nod to the Grinch and a Baby Jesus “it’s my birthday!” ornament is also nice 👌🏼. “Put the Christ back in Christmas” stickers are not.  The Seinfeld Festivus, Hannukah sweaters and Nutcrackers were a big thing at Tulip.

Politics, Sexual Identity, Reproductive Rights, Liberalism, Trump

See Religion above? Kinda?

Some corporations have decided that creating venues for expression of social ideas and discuss challenges in society is important. As soon as those venues (ie. Slack channels, seminars) are mismanaged at work, it is painful for participants.

As a manager, I prefer to focus energy on individual concerns and being an ally for my team members.  I celebrate the good stuff that impacts people on my team. I tend to stay out of their business unless my support / assistance is helpful.  People need room to explore this stuff without their boss reading their reaction Tweets.

Creating the air where your team feels respected for their work, and has the freedom to just be / breathe easily is purposeful; it’s the real work of building an inclusive environment.

Note: I started writing this in 2019 and now it’s 2022.  It may seem out of date or obvious, sorry!



Developers as TeamLeads

A common career path for software developers is into a “team lead” role.  On the surface it’s a very attractive role for the organization: a transition for dev’s interested in management, retaining some of that key senior-dev contribution, and avoiding a hire for a more traditional Manager role.

But its pitfalls are serious: TL’s generally struggle balancing individual contributor commitments vs. management responsibilities, and the perceived importance of each.

From personal experience, and from managing Team Leads, some tips!

Guard Your Time

Being a Team Lead requires you to be really aware of how you spend your time.  For example, time spent on lofty, heroic senior achievements can be less important than more predictable output, especially if others depend on you for their next steps.

Ask yourself these questions:

  • How much time can I set aside for individual work.  (2-4 hours per day is normal).
  • How much time can I dedicate to organizing or unblocking work, alignment, reporting, client calls, etc. (4-6 hrs/day)
  • Do I have direct reports? How much time will I dedicate to 1:1’s, mentorship, onboarding, etc. (1-2 hrs/week/person)

This split will impact team activities like pair/mob programming, whiteboarding sessions, etc. because you may not have long stretches of dedicated time available anymore.

The simplest way to visualize this challenge is to set up your calendar.

  • Block off dedicated slots for certain types of work (then guard them with your life).
  • Pro-actively book time with your team for work that you need to do together.
  • Identify things you have to do well, give yourself time to prepare (weekly demo’s to the CEO, client meetings, etc.)

.. knowing that it’ll change week-to-week, but have these rough proportions.

Most importantly, run this setup by your manager. Maybe they have a different vision about how to spend your time?

Focus on More Constructive Efforts

The “individual contributor” time Team Leads have needs to be used very constructively.

There’s a few ways to play this … some thoughts:

Taking high value, undesirable work (difficult-to-reproduce bugs, client escalations, etc.).  Those issues keep you connected with details, and identifies difficult things to mentor the team on.

Architecture and high-level software design for the team.  Something I found works well is scaffolding new capabilities, and being involved in that first week .. but letting the team fill in the blanks and iterate.

Technical documentation becomes more important as you’re more exposed to stakeholders, other teams, etc. Docs can influence more of the organization than your dev work does.

Code reviews can get overwhelming for any lead.  Good practice is to defer to the rest of the dev team, and focus your review attention on very important or risky deliverables.

Understand Perceptions of Your Contributions

Regardless of other duties, Team Leads are often perceived as “developers first”.  That can be positive or negative, depending on how you really want to contribute.

Navigating this perception of the role can be really challenging.

Personal story: I was leading a team of four on a new product.  The plan was ambitious and unlikely to succeed, so we had designed a better solution that would move the timeline, but more likely to succeed.

I went to my executive asking that we re-evaluate the promised timeline so we can deliver this better thing.  They started asking me about some current implementation detail that I wasn’t aware of. Then mentioned that I should know those details, and ignored questions about the plan.  It was frustrating; I felt under-appreciated.  Later I realised the mismatch with what the company expected from a Lead role, vs. what I was focusing my energy on day-to-day.

Building resiliency for those times, and being flexible enough to contribute on the many sides of the role, is tough .. but good for professional growth.

Hopefully you found this helpful,  and good luck with your Team Lead future.


Project Accountability using a matrix

Once projects get too large for a small team to run, people need ways to identify who is involved (and how) beyond the basic “on the team”.

Borrowed from project management best practice, an accountability matrix is a simple system used to communicate responsibilities on a project. 

Two things all the accountability matrices have in common:

  • have sweet memorable acronyms
  • have a point person who wrangles people into that matrix.


RACI is probably the most common accountability system. In RACI, the point person is known as the “Accountable.”  The acronym identifies the roles:

  • Accountable: single person who answers for the execution of the project.
  • Responsible: people engaged in the work of the project.
  • Consulted: people who weigh-in on the project, as SMEs. (Two-way communication)
  • Informed: people who want to know what’s going on. (One-way communication)

One person can perform many roles. For example, an Accountable is often Responsible as well.

RACI has critics and detractors.  Most of the criticism reflects that organizations take the matrix too seriously.   I like the point that Grumpy PM makes: the best use of RACI is identifying the various dysfunctions in the organization.

Define Responsibilities

The roles have assigned responsibilities.


  • A and R’s attend all project meetings.
  • R’s do most of the actual work.
  • C’s provide timely information, and attend meetings as invited, follow Slack conversations.
  • I’s read the status emails.

If someone can’t be relied on to do the above, they are likely not actually on the project.

For example, it helps identify if someone is a C (book stuff around them), or an I (don’t).  Changing people’s role on a project is straightforward: they get a new letter!

In Software Development Teams

Accountability matrices raise eyebrows and roll eyes due to origins in consulting and Deloitte-like environments.  I still like them. The concepts are lightweight and adaptable to help at a practical level.

Things I find helpful about a matrix:

  • Calls out when someone will actually need to be engaged, which can frees up time in calendars.
  • Divides work without stepping on toes.
  • Fun to make up your own acronyms.

My observation is that matrices that break up R into other roles (Supporting, Tasked, etc.) tend to be way too specific, and categorize people that can’t help the project directly.

Adopting This

Step one: add a bit of RACI to the “epic” or “feature” or “project” templates in your work management system (Jira, Trello, or whatever).  Your project will thank you!


The Employee Lifecycle, for New Managers

At some point early in my “management” career I realised nobody had sat me down and academically explained what managing people actually involved. I didn’t know what I was doing, other than being helpful-on-demand and organizing meetings. Being empathetic came naturally, but it felt like a failure when an employee wasn’t performing well. I didn’t always know what to do, and I didn’t really have the language to explain what I didn’t know.

Leading people was far less mystifying; I had been lead by good leaders, worked in groups where I was the leader, and “leadership” was a topic well-worn in TED talks and college papers. I had a framework for leadership in mind. But it wasn’t helping me convince someone that they shouldn’t quit after a boring project that under-utilised their skills.

Over time, many people helped me build a model of managing people, and it hinged on this idea that your job is to organize people’s lives through the employee lifecycle.

People get hired, become productive employees, and eventually leave. What they do in that lifecycle is up to you to manage. Tada, management.

Engagement and Performance

The lifecycle is organized into two important, somewhat binary, things about an employee:

  • Are they engaged, or not. Employee enagement is, as of writing, the best* predictor of employee success. This is something you can only get if you ask (with surveys, reviews, or 1-on-1’s).
  • Are they performing well, or aren’t they? This can be measured in many, controversial ways. As a manager you can generally answer the question “Is this person a high-performer, or not?”

The lifecycle looks like this:

The lifecycle of employees, and how to progess them through it.  The green area is the desired landing place for all employees.


Every employee starts the same way: someone recruits them. Recruitment is a shared responsibility in the organization, typically involving a dedicated talent management department (ex. HR).

Managers themselves need to:

  • Find and attract talent beyond what other departments are doing (ex. attend meet-ups, write tech blogs)
  • Screen, interview, and assess applicants.
  • Provide a good experience for everyone involved, as applicants talk to their networks.


Once an employee has been recruited, they are likely pretty engaged (unless recruitment didn’t go great). They are likely not performing at their version of “high level”. Developing an employee into a fully-functional member of the team is a managers responsibility.

Development is a continuous activity. An employee can highly function in one part of their role (ex. technical skills), but struggle with others (ex. leading a project, professionalism).  This changes over time, as new skills are required, and the job changes.

Developing employees requires managers to:

  • Onboard, and support their early learning and concerns.
  • Coach the development of required competencies, both professional and personal.
  • Set goals and provide progressive feedback; help overcome blind spots and local maximums.

This is different than training; development is personally tailored, and goes beyond core skills.


Employees find themselves in tough situations when they do not have the tools, or base skills required to perform parts of their job. It’s a manager’s responsibility to resolve those needs with training.

  • Identify under-developed core skills, particularly for groups of employees.
  • Create time in projects to pursue this “on the job.”
  • Watch for missing or incorrect tools, or usage of tools. (ex. wrong software, outdated guidelines)

Expecting people to train at home, or in the case of my industry on hobby projects, is a tad demanding and unpredictable.


Leaving the team (or the organization altogether) is an important moment in an employees lifecycle. Managing exits professionally, whether voluntary or involuntary, has a downstream effect on recruitment, and rest of the team’s engagement.

It doesn’t matter if the employee is let go, leaves voluntarily, stays with the company or not, a managers responsibilities are similar.

  • Prepare a replacement plan for every person on your team. Assume no replacement is coming.
  • Take part in the company “off-board”; administration can miss things that are team-specific.
  • Assess your team processes (ex. document ownership, meeting schedule) after every exit.
  • Maintain a conduit for a personal relationship; the time for learning from the experience may come later.
  • Keep the whole process positive and professional.

Exiting employees are actively networking and sharing their experience about your team with others.  They can either be building your bridges, or leaving negative Glassdoor reviews.


Very narrowly, retention is avoiding unplanned exits.  It’s expensive, disruptive, and bad karma to lose any employee (aka “churn”).

If you recognize someone is un-engaged and underperforming, the “exit or retain” decision should follow quickly.  Retaining means putting that person on a path to engagement (not necessarily high performance), and investing in their longer-term development.

This decision is difficult, and requires you to identify and address problems head on with the employee. That ruthlessness doesn’t always come naturally.

Preventing the “retain or exit” decision by setting up your team properly (including by hiring well) is the goal.

Retaining employees requires managers to:

  • Be clear and consistent about necessary behaviours and goals.
  • Foster a team identity that’s inclusive, honest, and aligned with business objectives.
  • Develop a personal “improvement plan”; the goals isn’t to make someone a rock-star, but set expectations on all those behaviours required to be successful.
  • Team-build; call out conflicts and have employees resolve them together.  Friends need strife.

The pattern here is managers retain people by being clear about: the team, it’s goals, and people’s roles on the team.


If you’ve taken management training since the late 1990’s, likely it was focused on engaging your employees.  Engagement supersedes concepts like “job satisfaction” and “morale” as a predictor of employee success.

Research that precedes this terminology still stands.  A formative, data-driven text on engagement is the (terribly named) First, Break all the Rules by the good people at Gallup.

Many activities required to engage high-performers are the same ones managers need to do in other parts of the lifecycle:

  • Ensure people have the right tools, equipment for the job.
  • Consistently communicate what is expected of the team, and the value of that work to the company.
  • Define plans for development and training.
  • Support development of team identity and friendships.

While retention requires setting up the team and roles, engagement focuses on the one-on-one relationship with the manager:

  • Know your employees as individuals, people with personal stories.
  • Find work that plays to their strengths and opinions; advocate for projects that match their skills.
  • Discuss their growth regularly
  • Plan strategies for getting promoted, compensation increases.
  • Recognize and celebrate successes; don’t wait for “announce-ables”, small wins that have creative output are great (ex. a well-written document that solved a client’s long-standing problem)

A lot like development, engagement is a continuous activity.  Like with skills, employees can be really engaged with one aspect of their job, or their team, and dis-engaged with others.   The challenge here is to develop someone to be well-rounded, and engaged with all aspects of the organizations work.

The Other Exit

The extreme end of the one-on-one relationship with your employee is identifying when to exit someone to bigger and better things, as perhaps they have outgrown the role you have for them.  Encouraging an employee onto a better opportunity is an act of being a great manager.

Hopefully you’ve found the above lifecycle helpful!  A good first step is to place your employees on the diagram above, and maybe your next one-on-one will prove insightful.