patkua@work

The intersection of technology and leadership

Category: Learning (Page 3 of 15)

How do I still write code as a Tech Lead?

November 11, 2014 / / 8 Comments

I have previously suggested that effective Tech Leads spend an ideal minimum of 30% of their time writing code. A common question I hear in the Tech Lead training course I run is:

Where do I find the time to code when I have all these other responsibilities to take care of?

I know that many Tech Leads struggle to find the right amount of code, and also struggle to know what sort of tasks to take on. Here are some useful bits of advice that have helped me and others:

Avoid working on critical path items

Although Gantt charts have a bad name in IT, they do serve a useful visual model for depicting critical chains and seeing the critical path. A Tech Lead will usually find themselves interrupted and finding a solid block of coding time will be unusual. As a guideline, I advise Tech Leads not to focus on critical path tasks because they will often block progress on those tasks.

If a critical path item requires knowledge or experience, that only the Tech Lead has, it is useful to work with another developer on the task, so that progress continues when the Tech Lead works on responsibilities.

Learn to delegate

Delegating is a skill that Tech Leads must develop, and a skill that developers rarely have an opportunity to build. The Situational Leadership Model clearly explains when to delegate. Effective delegation depends on the skill and motivation of an individual. The model explains four modes: Telling, Selling, Participating, Delegating with the end goal of aiming to delegate as much as possible.

Delegating is only possible when a leader believes someone has the sufficient skill and sufficient motivation to complete a task.

A common challenge for many Tech Leads is trusting that someone other than them writes code good enough to complete an appropriate task.

Loosely pair program

I’m not a big believer in full time pair-programming. But finding the right balance between full-time and nothing is hard to achieve. A good arrangement is to work with someone on the approach or design for a particular problem, and then to do regular reviews (or short pair-programming sessions) to see what new information or challenges emerge as code is written.

This style of “co-working” on the design and code works well for a Tech Lead, who will find themselves constantly interrupted.

Avoid unnecessary or poorly run meetings

There is nothing worse for a programmer to sit in a meeting which has no purpose or no outcome. These are frustrating because the time spent in the meeting is waste. Learn how to run effective meetings, to avoid the frustrations of ineffective meetings.

Use the “5 P’s of Effective Meetings” model:

  • Purpose – Is it clear what the meeting is for? Ensure each meeting has one clear purpose. Examples include: Distributing information, gathering information, brainstorming solutions, and seeking agreement or consensus.
  • Product – You can cut a meeting short, when you know what the outcome of that meeting should be. Define success criteria for the meeting (which will be related to purpose) to keep meetings focused and on track.
  • Participants – It is better to cancel/reschedule a meeting than to hold a meeting with the wrong people. This tweet from Esther Derby summarises it very well. Pointless Meetings
  • Probable Issues – What are the concerns or questions that will be raised during the meeting that need to be addressed, or threaten to derail the meeting?
  • Process – Every meeting should be clear about how the meeting will be run, how people are expected to participate, and special rules of what might need to be done. A meeting facilitator should start with clarifying the purpose of the meeting to reset people’s expectations.

Learn to say no

The art of leadership is saying no, not saying yes. It is very easy to say yes. — Tony Blair

As a Tech Lead, you will be pressured to always take on more than you can possibly take on. The more activities you say yes to, the less time a Tech Lead has to code. If coding is really important to you (and it should be), then you need to develop an awareness of what things are really important and those that can be done by others or by non-technical people.

Block out coding time

I know some Tech Leads who block out calendar time in their diary on a regular basis to ensure that they have uninterrupted time to code. Developers know how interruptions break the train of thought and Tech Leads will find themselves even more interrupted in comparison to developers.

Conclusion

It is important a Tech Lead spends time writing code but the other responsibilities demand time away. Keeping the balance right is tricky, but the techniques described above can help you cutting code. Please leave a comment if you have other suggestions.

If you liked this article, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.

From Flickr (https://www.flickr.com/photos/susivinh/7019888809) under the CC licence

Book Recommendations for a Tech Lead

October 24, 2014 / / 3 Comments

I gave several training courses on being a Tech Lead and found myself giving a number of book recommendations. Although books are no substitute for experiential learning and close feedback cycles, they are useful as ways of introducing some key skills developers rarely practice in their day-to-day tasks.

Dealing with people

Tech Leads are leaders for an engineering/development team and will need to learn the right skills to deal with the unusual world of people. People are different, unique and have their own styles which may or may not align with your own.

Leading Snowflakes Leading Snowflakes is a good e-book, aimed at Engineering Managers who need to deal with different situations. Although it goes beyond just the people aspects, it is still a good book that focuses more on the people side.

Managing Humans Managing Humans (3rd Edition) is written by Rands & Repose author, Michael Lopp. It’s a humuour collection of stories describing the weird and wonderful world an Engineering Manager may find themselves facing. Most, although not all, of the stories will be relevant for Tech Leads. Thanks to Alex for this book recommendation.

Turn the ship aroundTurn the Ship Around is a great leadership story that talks about how leaders should be enabling other leaders using an example story of how a certain leadership style turned around one of the world performing US navy ships into one of the best. Thanks to Joe for this book recommendation.

Negotiation

A Tech Lead represents both the technical perspective to outside stakeholders, and often carries a business perspective back into the technical team. Conflict is inevitable and understanding how to negotiate to an optimal solution for two parties is a timeless skill.

Getting To YesGetting to Yes was one of my favourite books. It’s short and insightful. The book describes the different between Positional-based negotiation (typical) vs Interest-based negotiation. Thanks to Jo for this book reommendation.

Getting Past NoGetting Past No (Fisher) is the sequel to the book above that describes getting through more difficult conversations. Jason Yip recommended this book.

Crucial ConversationsCrucial Conversations is a great book talking about how to have conversations when the stakes are high. They also have another great book called Crucical Confrontations that shows you how to have those difficult conversations that matter. Thanks to Clay for this book recommendation.

Facilitation

Meetings. Meetings. Meetings. Three dreaded words that a developer doesn’t want and often can avoid. A Tech Lead often dreads the numerous meetings as well, but will be often expected to contribute. Most meetings will be poorly planned and facilitated, leading to even more drawn-out meetings. In my experience, when done well, meetings can be focused, short and fruitful when they are well-facilitated. Facilitation skills are also useful on a day-to-day basis when ad hoc meetings between team members occur, or when a particular topic needs to be discussed.

The more collaborative a team becomes, the more useful facilitation skills are to the Tech Lead as they blur into the background to all voices be heard.

The Skilled FaciliatorThe Skilled Facilitator (Schwartz) is the first book I recommend to new facilitators. I find the book easy to read and is comprehensive in its explanation about the role of the facilitator.

Facilitator's Guide to Participatory Decision MakingFacilitator’s Guide to Participatory Decision-Making (Kaner) is a more focused book, covering how to have group discussions, balance hearing all views and to converge into the best outcome.

Collaboration ExplainedCollaboration Explained (Tabaka) is written by an agile practitioner who I trust dearly. I have see her facilitate, and her wisdom is captured in this book that will be highly relevant to particularly agile teams.

http://amzn.to/1wzIYHDSecrets of Facilitation (Wilkinson) is a book recommended by Jason Yip.

Risk Management

With authority comes responsibility and the Tech Lead suddenly sees risks everywhere. Or worse, they don’t see any risks at all.

Waltzing with BearsWaltzing with Bears (De Marco and Lister) is the timeless book that talks about risk management in the settings of software development. Although some of the examples may feel a bit outdated (death march projects), our industry still has plenty of them and the lessons are still relevant for today’s style of software development.

The Failure Of Risk Management
The Failure of Risk Management (Hubbard) is another book recommendation from Jason Yip. Now added to my reading list as it’s one I haven’t yet read.

Not just for Tech Leads

Unsurprisingly the book recommendations above are not only relevant to Tech Leads, but to anyone who may find themselves in a leadership role. There are plenty more skills and books to recommend, but these are a good starting set.

If you liked this article, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.

Booklist from the Retrospective Facilitators Gathering 2014

May 19, 2014 / / 0 Comments

The Retrospective Facilitators’ Gathering is the only conference I planend on attending in 2014. Like many conferences, I end up with many books to read, and thought it’d be worth sharing the list I accumulated here:

Book Review: The Art of Learning

December 4, 2013 / / 0 Comments

I like reading books that describe how people grow. It’s useful as a Technical Leader to help you grow your team, it’s useful as an agile coach to help people build new skills and useful to you to look at how you can grow yourself. Thanks to pop-economics books like “Outliers” people might spend 10,000 hours working on a skill but never really master it. As I have heard people say before:

You don’t develop mastery by doing the same thing over and over again

Here’s a good post why top achievers 10,000 hours may be different to yours.

The book is written from the perspective of Josh Waitzkin, a guy who has had an incredible life mastering a couple of disciplines that couldn’t really be any further apart, Chess and Pushing Hands. He’s even had a movie made out of his life.

The Art of Learning Book

What I liked about the book
Waitzkin has already led a life ripe for several movies, and he describes his journey like a story book unfolding. I found it engaging because it is personal. He writes about detail that others could not know and he’s happy to disclose difficult parts of his life. I think these details made me relate to him much more.

I sensed he thinking deeply about himself, and in a way, observing this in his writing gave me respect he already knew a lot about learning (it’s hard to get better if you have no idea what you’re doing!) He isn’t particularly prescriptive about his learnings

I find it clear that he thinks deeply about his own self, and in a way, I think that makes him already very effective as a learner. He isn’t particularly prescriptive about his method of learning, talking about some general steps that take the form of chapters and draws upon his own personal anecdotes to make examples of them.

What I didn’t like

Although I found his personal stories captivating, I felt they were slightly embellished because of the way he discusses what other people were thinking during certain events (particularly during competition). Take it with a grain of salt, but it slightly tarnished some of the storytelling for me.

I also enjoyed the linking of the personal journey to the chapter titles, but would have been useful to have a summary providing insight into making it a bit more practical concrete. Reading other reviews on sites like amazon also give people some of this frustration.

His two personal situations were focused on competition and I think reflections some of the emphasis of “another opponent”. I found this difficult to translate into learning skills for self-development where you aren’t “opposed” to a single person such as learning a language.

What I learned

His chapter Using adversity gave me examples of how to turn difficult situations into learning opportunities. His drive and motivation reinforce other ideas about learning I have read about (that it’s about dedication and not necessarily innate skill that drives success).

The chapter Slowing down time reminded me about the differences between expert and beginner’s mindset that demonstrate what is “magic” to one person is perceived differently and working on how to break the “magic” into smaller, learnable, and practices steps accelerates the learning process. I think this requires a lot of self-perception, and the importance of exposing yourself to more difficult, challenging situations.

Conclusion

I gave this book away to someone recently because I felt they would benefit from it. However it is definitely one that I will be trying to read again sometime as I am sure to have a different insight by focusing on different areas. If you’re interested in learning, this is an enjoyable book that teaches some good principles but lacking concrete actions. Still recommended reading.

His personal stories are particularly captivating, but I find it difficult for him to conclusively draw what other people were thinking in the way that he describes

Book Review: Quiet

November 27, 2013 / / 0 Comments

I have read more books recently with so much more travelling. Susan Cain wrote the book I finished most recently, called Quiet: The power of introverts in a world that can’t stop talking. A provoking title and filled with a good level of research and stories talking about how today’s society views introversion as a negative trait, but can actually provide people and organisations with positive outcomes.

Quiet

What I liked about the book

Cain provides a different, refreshing perspective about the strengths introverts can offer. She highlights (mostly American) cultural influences that make it difficult for people with introverted tendencies to operate and some practical suggestions along the way on balancing the needs. For example, introverts often need time to digest, prefer to do deep analytical thinking and need time to restore after heavy interaction with many people. Another example is that extroverts tend to take more risk, particularly under stressful conditions, while introverts tend to take more take.

The book made me think about practices like “pair programming” and how agile methods impact introverted people and their need for space. Sidenote: I don’t see agile methods working against introverts but just that necessary balance must be found

I particularly enjoyed the section where Cain discussed how people with different extroversion/introversion tendencies can find a way to live, work and love together. It reminded me of interests based negotiation over positional based negotiation and that if people focused on what their needs were, instead of outcomes, they might find a new, slightly different solution that work for both parties.

What others might struggle with in the book

Although Cain references a lot of research, the contents appear to me more anecdotal. She approaches this early in the book, writing about different definitions of introversion and peppers disclaimers throughout the book that “not all introverts act the same”. She also references studies but warns they are not conclusive because these are in early stages. For some, this may be a killer, but for me, still provided an interesting read.

At times, the guidance can be confusing. In some parts of the book, the message I took was that introverts don’t need to adopt extrovert characteristics. In others, I felt like the guidance changed to sometimes introverts need to adopt extrovert characteristics but they will need to time recharge and it helps to do so in areas you enjoy.

Conclusion
In some part of the book, Cain describes the world being at least thirty to fifty percent being made up of introverts. Some may be better at hiding it. I think everyone should read this book to understand more about a group that will naturally be more quiet and why that is.

Disrupt yourself, or someone else will

October 25, 2013 / / 0 Comments

A couple of days ago, Apple announced their new range of iPads including a mini with a retina display and a lighter, thinner full-sized iPad. Notice anything strange about their prices?

iPad2 Pricing

As can see the new mini retina priced at exactly the same price point as the (old) ipad2. Seem strange? You’re not the only one to think so as outlined by a comment from this appleinsider article.

Comment

This isn’t the first time Apple have priced a new product at the same as an older product (and probably won’t be the last).

The Innovator’s Dilemma
In the book, The Innovator’s Dilemma: When New Technologies Cause Great Firms to Fail, the author shows organisations that fail to embrace new technologies because they focus on the success of a single product or technology.

By offering these lines (new and old) Apple effectively segments their market into the early adopters of technology while providing (older and probably less appealing) options to all others. A conflict of features (retina display in a smaller form factor) makes users decide what is more important to them.

By removing the older iPad2, they effectively force consumers to move to the new platform and some of their customers may be happy with the existing product. Apple is effectively disrupting themself before their competition can.

Uses our cognitive biases

Having the same price point for a newer technology also taps into the anchoring cognitive bias (sometimes called the relativity trap).

Without the older product in the lineup, the newer products would not appear so appealing. The “anchor” of the older product is effectively pushing people to the newer products.

A person would ask:

Why would I buy older technology for the same price?

and then make the trade off for a smaller size, or if they want a newer size, pay another premium for it.

Book Review: The Power of Habit

October 22, 2013 / / 2 Comments

After a twitter conversation with Rachel Davies, I wanted to read a book about change, and so I decided to read The Power of Habit: Why We Do What We Do, and How to Change by Charles Duhigg. After reading the first chapter, I realised that I had read the book but neglected to write up my thoughts, so I thought I would re-read the book.

The Power of Habit

Much like many business books, this book is full of anecdote’s and stories to help reinforce the habit loop. Early on the book talks about the habit cycle that once formed, is often very difficult to break. It involves a simple three step process that our brain reinforces over time as a way of saving energy in the brain. The author tells about research into rats that displays the difference in brain activity when a rat is first exploring a maze, compared to one that they are are used to navigating which they habitually navigate based on expecting a reward.

The habit loop

Habits save time
Habits are interesting because they save us time, but of course, perils lurk when habits have bad consequences such as drinking, gambling or unhealthy eating (probably one of my worst habits!). Fortunately the author focuses on understanding what things we can do to adapt behaviour.

We cannot stop a habit, only override it with a stronger one
With my understanding, small changes in the environment might not trigger our habits and if we can work out our cues, we might be able to stop the behaviour we want to change. However if we cannot change the trigger (or we cannot identify the trigger), we cannot often stop the habit. We can, however, create a stronger habit that overrides the other habit if we can connect the cue and reward, simply replacing the behaviour with an alternative habit. We do have to be careful though because our underlying habit still exists, and we might still revert to it under times of stress.

The strength of our mind
Another interesting point is the power of our own mind in that for change to stick, we really have to believe it will work. Very similar to the placebo effect cognitive bias, our minds are amazing machines and sometimes the power of willing it to be so makes a big difference to whether or not something works. This is often why some people talk about change only sticking when someone has a crisis because it is at this critical point where a person will fully commit to (and believe) an alternative.

Keystone habits
The book moves on from individual habits to organisational habits and from here, I felt the book explained the emergent behaviour out of a complex system through the lens of habits. For example, they talked about the organisational shift Alcoa went through when Paul O’Neill mandated a focus on fixing safety in their organisational.

The author describes this relentless focus on improving safety as a “keystone habit”, or a habit that if changed had the ability to trigger multiple other changes. In a systems thinking world, these would be leverage points or root causes. Same idea, explained differently.

Conclusion
I found The Power of Habit: Why We Do What We Do, and How to Change an easy book to read, and offers a lot of insight into why we might behave as we do in certain ways. I like its suggestions about actions we can take to create change, although I don’t necessarily agree with all of the anecdotes as I believe there are other ways of explaining the situation.

Retrospectives as tools for change

July 8, 2013 / / 1 Comment

Jutta Eckstein recently asked me to write a few sentences about my perception of “Retrospectives as tools for change.” After writing my response, I thought it would be worth publishing here.

I see retrospectives as an effective seed for starting change within a group of people whose ultimate outcome depends on each other. I find they can build a shared context in a place where each person holds different “parts of the puzzle” in their head. When executed well, retrospectives also establish opportunities for the group to progress the way they work, improve their environment and build better relationships between group members.

I do not see retrospectives as the only opportunity for change. I also believe they do not guarantee change. I believe they certainly help, and I am definitely in support of that.

Reflecting on Feature Leads

January 17, 2013 / / 0 Comments

Last year, I wrote about trialling the idea of Feature Leads. I think the idea worked out and I would encourage more teams to adopt this approach. It helped devolve some of the responsibility and made the work more engaging for developers. Looking back at the list of things to consider, I would now add more items.

What is missing list?

  • New environment needs? – Do we require new environments to support business stakeholders in their own testing, or do we overload an existing environment? If we rely on external dependencies, can they support the number of environments that we need.
  • Identify external dependencies – If we are working with external vendors, we need to probably be a bit more upfront in working out when key dates are so that we can co-ordinate
  • Has the business made any external/internal commitments – As much as teams get frustrated by arbitrary dates set by the business, it’s useful to know if a) any have already been set, or b) business stakeholders want to communicate dates because that means you need to manage expectations and ensure that those commitments are balanced with other priorities going on.
  • Is the solution simple, but evolvable – Does the approach make any anticipated work harder than it needs to be? Does it balance out time to market? Can we go for an even more lightweight solution and substitue a more complex one later if needed?
  • Do we need to build anything for the feature? – Is software even needed, or can some lightweight business process take care of the need? If we build this, how long will be used, and therefore how much effort in maintaining it/adding automated tests around it?

Looking back at the list of responsibilities, I think these elements help add to a standard list of what things to consider when designing any sort of software solution, and not just the building of it, but thinking about the long term effects of it (who uses it, who’s going to run it, who’s going to maintain it).

Looking back at a year with a client

December 7, 2012 / / 1 Comment

Over the last twelve months, I’ve worked with a client to rebuild a digital platform and a team to deliver it. It’s now time for us to leave, and a perfect time to reflect on how things went. The digital platform rebuild was part of a greater transformation programme that also involved the entire business changing alongside at almost all levels of people in the organisation. The programme also outlined, before we arrived, outlined a complete change in all technology platforms as well (CRM, CMS, website) to be rebuilt for a more integrated and holistic service offering.

Our part in this program turned into building the new web digital platform, working against a very high level roadmap, and a hard marketing deadline. We ended up building the site using Ruby on Rails serving content driven by a 3rd party decisioning platform (much like Amazon recommendations) guided by the business vision of better tailored content for end users. We didn’t have much input into the final choice of several products. I’m very proud of the end result, particularly given the tense and short-timed framed environment in which we worked. Here are some examples of constraints we worked with:

  • 4 Product Owners over the span of 11 months – From January this year, through to the end of October, the business was onto its fourth Product Owner for the digital platform. Building a consistent product is pretty much nigh impossible with changing product hands, and trying to bridge work from one Product Owner to the next was definitely a challenge.
  • Constant churn in the business – The 4 product owners is one instance, but we would often be working with people in the business to work out what should be done, only to find that the following week they were no longer with the business.
  • 3 Design Agencies engaged resulting in “reskinning” approved by the board before the 6 month public launch – We saw several “design changes” done by firms well stocked with people capable of generating beautifully-rendered PDFs that were signed off. However often these would imply new functional work, or be impractical to the web medium.
  • Marketing deadlines announced well before the development team had been engaged – A common pattern in the business was marketing launching a press release announcing a date, well before the people involved in delivering it were made aware, or even consulted on it.
  • PM Explosion – At one point, it felt like we had more Project Managers on the group planning out work with budgets and timelines that would be approved well before the development team had been approached.

Even with these constraints we’ve been able to deploy to production 37 times in the last three months and more since the original MVP go-live in July. Part of what I’m particularly proud of is the team where we were able to achieve the following:

  • Building an Evolvable Architecture – We questioned the original choice and need for a CMS but with a constraint that a decision had been made on buying these tools, we architected a solution that would hide the implementation details of the CMS via a content service. With our TW experience and pain dealing with CMSes that are shadowed by business need, we wanted something that would not constrain what the business could achieve (hence the decoupling). We even had a chance to prove this out when the business requirements quickly hit the limit of the CMS’s built in categorisation module.
  • Responding to Change – The business roadmaps seems to change on a daily basis, and our team was able to quickly tack to accommodate these business changes. We changed the team structure as the team size increased, changed the team structure as we went live, and again as people in the business changed. Whilst our process felt similar, it would look nothing like a textbook XP, Scrum or Kanban process.
  • Improving the Process – Our team has been constantly trying to change the process not only internally to the development team, but also helping people in the business find ways of improving their own way of working. Progress has been slow as the change that starts falters as people leave. Retrospectives have been a key tool but also has the ability for the team to feel empowered with recommending and pursuing improvements they see fit.
  • Setting an example of transparency – Showcases are key to the business, and we would offer fortnightly showcases to the features built to the entire organisation. Huge numbers of people came along and I found it fascinating that it was one place where people had an opportunity to talk across silos. This sometimes slowed down our ability to show what we had actually done, but I felt exposed missing communication structures that people still needed.

At a technical level, I’m really proud of some of the principles I wanted to achieve at the start and that the team lived throughout (I’d love to hear what their experience is). Some of these include:

  • Fast developer setup – Getting started on each new machine should be fast without complicated installation processes
  • Developers rotating through operations – There’s nothing like supporting the code you wrote to help developers understand the importance of logging, test cases that are missed and just experiencing what production support is like
  • DevOps culture – Everyone on the team is capable of navigating puppet, knowing where to look for configuration changes and ensuring that applications are configurable enough to be deployed without special builds across environments.
  • Continuous Delivery – Our second product owner (the first transitioned out the day we went live) actually asked for us to release less often (i.e. it is a business decision to go-live) so that they could work with the rest of the business to ensure they had their non-IT dependencies in place.
  • Devolved Authority to Feature Leads – I blogged previously about Feature Leads who could help shape the technical solution and drive the knowledge for the project.
  • Metrics Driven Requirements – Though not completely successful, we were able to stop the business from implementing some feature by showing them production metrics. In this case, we were able to avoid building a complex search algorithm to show that we could achieve the same result by adding to a list of synonyms on search.
  • Everyone grows – If I look back at the project, I think everyone on the team has experienced and grown a significant amount in different ways. I think we struck a good balance between being able to work towards individuals goals and find ways they could help the project at the same time.

Other particular things I’m proud of the team:

  • Taming the Hippo – Worthy of its own post, Hippo CMS has been one of the least developer friendly tools I’ve had to deal with for some time. The team managed to work out how to run an effective functional test around its poor UI as well as deploy and upgrade the beast in different environments without the 12 step manual process outlined on their wiki.
  • Rapid team size – Management wanted the entire team to start at the same time. Even being able to push back, we ended up with a very aggressive ramp up and we still managed to deliver well.
  • Diverse but co-operative – We had something like 17 people and 14 different nationalities and it’s one of the strongest teams I’ve seen who were able to work through their differences and forge ahead.

Things that I would like to be different:

  • Find a way to code a lot more – Due to the circumstances, many elements drew me away from coding. At best, I can remember pairing with someone for at most two days a week (for a short time) and I would like to find a way to do that more.
  • Implement more validated learning – Although dependent on a product owner willing to do this, I would have liked to work more on trying to build and experiment a lot more.
  • Have a stronger relationship with decision makers with authority – I believe development teams work best when they are connected to people who can make decisions, not just organisational proxies who provide answers. Unfortunately I felt most of this cascaded very far up the organisation and due to the constant flux and organisational change, this wasn’t possible in the timeframe. I’m hopeful that as the business matures and more permanent people find their place, this will be more possible.
« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders Noren — Up ↑